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

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Benjamin Geer <ben@socialtools.net>

>  > let proc o = (new thing_processor)#process (o :> fbbq);;
>  > proc et;;
> 
> I've thought some more about this idea of wrapper functions, and 
> actually, it doesn't seem simple at all.
> 
> In an object-oriented program, *all* methods are potentially 
> polymorphic; this is what makes object orientation useful.  It means 
> that you can always pass, to a method in class C, an instance of a class 
> that didn't exist yet when C was written.  A library's author therefore 
> doesn't need to anticipate all the classes that will ever use the library.

This *all* is clearly wrong.
Even in a purely object-oriented language like smalltalk, you have
methods with no arguments. And since ocaml is not purely
object-oriented (Java is not either), you have plenty of methods which
take only non-object arguments.
Even for object arguments, not all classes make sense when extended.

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)

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. This way you just have to write
    printer#print obj#printable
in place of a coercion, which may be shorter and avoid strange error
messages when failing.
To do this you just have to add the following to the printable virtual
class:
  class virtual printable = object (self)
    method virtual ...
    method printable = (self :> printable)
  end

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.

> Doing coercions at the call site is equally cumbersome, and you lose the 
> ability to change the method so that it accepts a less derived class.

Arguably true (even with coercions methods). However you should not
overstate the problem. Clearly, you are talking of a case where
recompilation is needed. This means that you have the source code.
The great strength of ML is that the compiler is able to pinpoint all
necessary modifications. Hardly a big deal.
If you were using Java, you would have to write explicit types for all
local variables. This often makes similar type changes much more
cumbersome in practice.

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. Overall object-oriented languages are much weaker
than functional languages at changing design afterwards.

Jacques Garrigue

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