Re: [Caml-list] Re: OCAML Downcasting?

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

From: Michael Vanier <mvanier@cs.caltech.edu>
> > From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
> > 
> > There are two important differences between ocaml and other
> > OO-languages that have downcasting.
> > 
> > - inheritance is not subtyping. The subtyping relation being
> >   structural, a full fledge typecast would not only require to keep
> >   type information at runtime, but to embark a large part of the
> >   compiler to check subtyping. This might also be incredibly slow.
> > 
> >   As a result, downcast is only reasonable when we have both
> >   inheritance and subtyping. You're suddenly losing a large part of
> >   the language.
> 
> But java has interfaces (subtypes), and classes can implement interfaces
> (making them subtypes of the interface) without inheritance.  Furthermore,
> the class identity can be retrieved from an instance of an interface by
> using the instanceof operator.

Java interfaces are actually closer to inheritance than to subtyping.
For a class to support an interface, you must declare it when you
define the class, and you have no way to add a new interface
afterwards.
With ocaml class types, you can coerce an object to any type whose
methods it implements, even if the object comes from a class actually
defined before this class type.

For this reason, I would rather compare java interfaces to purely
virtual ocaml classes. Implementing a java inteface then amounts to
inheriting from a class whose methods are all virtual.
This is closer, because a java class includes extra code for all the
interfaces it is supposed to implement.

>From an implementation point of view, java interfaces are just a hack
to work around the absence of multiple inheritance.
And not very efficient at that: method calls through interfaces can be
slower than ocaml method calls, which have to be completely dynamic.

> >   Worse, even if you have a module interface
> >      class b :
> >        object
> >          inherit a
> >          ....
> >        end
> >   in ocaml this does _not_ mean that b inherits from a, just that it
> >   has at least a's methods and fields.
> >   So the semantics of downcast would not allow abstraction.
> 
> I don't understand the point you're trying to make here, but it seems like
> a is effectively equivalent to an interface in java (at least from your
> description).

The point is that b may actually have no relation whatsoever to a. It
just happens to implements all a's methods, and as result the above
syntax can be used to make the declaration shorter. If downcasting
were to depend on the inheritance relation (and in java it does, if
you rightly consider all the "implements" as weaker versions of
"inherits"), then there would be no way at runtime to see b as a
subclass of a, eventhough the above declaration lets you think this is
the case.

> > - classes may have type parameters. Assume a situation like
> >     class ['a] a = object ... end
> >   Then we cannot downcast any runtime object to "a", because we don't
> >   know what is its type parameter. Again, downcast would not mix well
> >   with other features of the language.
> 
> Java now has generics (type parameters), and I assume that it has to get
> around this situation somehow.

Well, I tried today with 1.5beta2, and it simply doesn't.

Actually, generics only provide very limited type safety if you start
using casts.
Look at the following program:

import java.util.*;

class Testgen {
  public static void main(String[] argv) {
      ArrayList<Integer> l = new ArrayList<Integer>();
      Object l1 = l;
      ArrayList<String> l2 = (ArrayList<String>)l1;
      l2.add("Hello");
      Integer n = l.get(0);
  }
}

When you compile it, you get a warning about the cast
(ArrayList<String>) not being checked. When you run it, you get a
runtime type error on the last line: not even when you try to add a
string to a list of integers, but when you extract an integer from a
list of integers!

I believe C# intends to do something better, but this is going to be
rather heavy-weight, and their subtyping relation is much simpler than
ocaml's.

> > So, while this is somehow unfortunate, there is no downcast in ocaml.
> 
> I'm sure there are good reasons for this, but I don't find the arguments
> you've presented above persuasive.  Not that I'm trying to hold java up as
> a shining example of the Right Thing; I'd much rather program in ocaml than
> java any day of the week.  But the lack of downcasting has frustrated me in
> the past (it's my #1 gripe about ocaml, with the lack of support for
> native-code shared libraries at #2).

There are various type-safe idioms to support downcasting.
Maybe it would be a good idea to collect them somewhere.

Yet I think that other people's comments are right: there are often
better ways than downcasting. They may mean that you lose in
modularity, but in my opinion you gain more in safety.

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