Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass

["chris.danx" <chris.danx@ntlworld.com>]

John Prevost wrote:

[snip]

> let use_get_x o = o#get_x
> 
> Here, the function "use_get_x" can be used on instances of any class
> that contains a method get_x : unit -> int.  This is called
> "structural subtyping".  The subtype relationship is based purely on
> what methods exist, not on what classes have been declared to be
> subclasses of others.

I didn't realise OCaml supported this.  I wanted to write code like that 
but didn't realise it was possible in OCaml.  This opens the door to a 
new way of writing programs.  Thanks!

> At this point, you may be wondering "Why is O'Caml like this?  Is it a
> good thing to separate subtyping and subclassing this way?"  So I'll
> give a couple of examples of how this type discipline is less of a
> pain than the one used by Java.

It's not so strange to me.  Separating subtyping from subclassing is 
something I'd read about (in the context of polymorphism and 
subclassing) and thought was very useful.  It gives you the ability to 
write code that works over different classes of object, without 
specifying the precise type of the object (it's type is implied by the 
methods it has).  This is why I didn't realise OCaml provides the 
ability to do this.  I'd assumed that the typing rules of OCaml enforced 
the fact that the methods and classes had to exist before the inference 
of the type was done and that it'd be one of those classes.  Thinking 
about it that doesn't make much sense.

Now it's clear how the new immediate objects work.  It was a bit 
puzzling before, as there seemed no way to use them.  Immediate objects 
seem to make it trivial to write something like a proxy providing you 
know the methods before hand.  A more interesting case would be if you 
didn't know the methods before hand but you could access them in someway 
and build objects at runtime and you could somehow guarantee the result 
was compatible.  Not sure how that'd fit with OCamls typing scheme, but 
it's interesting to think about.

> 1) Implementing multiple interfaces.

...

> 2) Subclasses that are not subtypes

...

The first one is easy to understand, but the second example took a while 
to get my head around.  I think I understand the implications of it now, 
although it is still a bit unclear to me how the reuse works in this 
example.  I sort of understand it, but bits of it are unclear.  Need to 
think about it for a while.

> I hope my long-winded explanation was useful.

Very!  OCaml is a big language - in the sense there's a lot of power 
there - and some of it is still hidden to me so I appreciated your 
explanation.


Thanks,
Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners