Re: [Caml-list] does class polymorphism need to be so complicated?

[Benjamin Geer <ben@socialtools.net>]

Jacques Garrigue wrote:
> Even for object arguments, not all classes make sense when extended.

The problem is that it is often difficult to know, at the outset, 
whether it makes sense for a class to be extended.  Sometimes you start 
out with a concrete class, thinking 'no one will ever want to extend 
this', and later you realise that it should have been an interface, 
because there's a real need for different implementations.  It's easier 
to change a class into an interface if all methods that use the class 
don't also have to change, i.e. if the syntax for using an interface is 
the same as the syntax for using a class.

Another approach is to use interfaces for everything.  But then you 
really need a lightweight syntax for handling interfaces in methods.

> So we are back to an often fairly small number of methods (in my
> experience one or two by big class, but it may depend heavily on your
> design)

See my last message, about writing and using libraries.

> Another approach which was not described yet, and which I use in
> lablgtk for instance, is to add a coercion method to classes which form
> the top of a hierarchy. [...]

I agree that this is a slight improvement; it's basically a shorter 
coercion syntax.  Why did you decide to use this approach in lablgtk, 
instead of the other approach you suggested (using virtual methods that 
accept class types)?

> This all depends of the number of methods taking printable as
> argument.  If there are only a few of them, wrapping functions or
> polymorphic methods are probably a good idea. If there are lots of
 > them, then adding such a coercion method may make your design clearer.

It's often difficult to know, at the outset, how many methods will 
ultimately use any given class, particularly if you're writing a 
library.  Perhaps initially there will only be a few, and later on there 
will be many.  Object-oriented programming should mean that you don't 
have to know or care.

The point about clarity is interesting, though; you seem to be saying 
that coercions make code clearer.  While this may be true, the whole 
philosophy of ML seems to be about giving the programmer a choice: type 
specifications are necessary only when there is ambiguity, and are 
optional elsewhere.  Since there is no possible ambiguity in the case 
we're talking about, wouldn't you rather have the choice?  This is why 
the approach using 'open rows' seems more appealing to me.

> And if you're going to change the requirements of a method in the
> middle of your development, this means that there was something wrong
> in your design.

Unfortunately, as hard as we may try to create the perfect design, 
designs always change over time.  I think programming languages should 
try to make those changes as painless as possible.

Ben

-------------------
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