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

[Brian Hurt <bhurt@spnz.org>]

On Tue, 21 Sep 2004, Michael Vanier wrote:

> 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 also has run time type identification, something Ocaml doesn't have.  
And generally doesn't need.  Downcasting, however, requires RTTI- I hand 
you an object of class foo, you think it's really an object of class bar 
(which inherits from foo), and want to turn the foo into a bar- but how do 
you know it's *really* a bar?  It might just be a foo, it might be a baz 
(a different class inheriting from foo).

The general solution is to rethink the problem to avoid the downcast.  
Some general platitudes: first, avoid upcasts.  Try using column types 
instead.  Second, move the operations that need the downcast into the 
object itself- delegate (the object knows what sort of object it really 
is, even if you don't).  Third, ditch objects.  Java, C++, etc. strongly 
encourage you to think of everything as an object, try designing the code 
sans objects and see how it works.  Fourth, hand implement RTTI- either by 
adding member functions to the base class to do the conversion (throwing 
an exception if the conversion is bad), or using a variant type.

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

If I understand it correctly, they basically lifted C++'s templates more 
or less verbatim.  I don't have experience with Java Generics, but C++ 
templates create a whole new copy of the class for every type they handle.  
So that List<short>, List<int>, List<float>, List<foo_t>, etc. all use 
different instantiations.  How C++ gets around it is that if you have a 
template<class t> class foo_t, bar_t doesn't so much inherit from foo_t, 
as bar_t<int> inherits from foo_t<int>, etc.

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

Downcasting is a sign you're doing something wrong.  If you knew the 
object was a bar_t, why didn't it have the type bar_t from the get-go?  If 
you don't know it's a bar_t, how do you know it's safe to cast it to a 
bar_t?  Without RTTI, that is.

By the way, RTTI costs memory (at least one extra word per object, plus 
the overhead of the Class classes for all types).  Plus- does RTTI apply 
to non-objects?  Ocaml has a lot of types that are not classes.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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