Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Re: OCAML Downcasting?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-21 (22:06)
From: Michael Vanier <mvanier@c...>
Subject: Re: [Caml-list] Re: OCAML Downcasting?
> Date: Tue, 21 Sep 2004 16:38:25 -0500 (CDT)
> From: Brian Hurt <>
> Cc:, <>
> 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).

Yes, I was assuming RTTI, which is what the instanceof operator provides.

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

Um, no, they didn't.  In fact, it's a completely different mechanism.  The
compiler erases the generic information so that the JVM sees only old-style
java classes without parameterization and adds casts where needed.  OK,
this wasn't the greatest example in the world, because it relies massively
on RTTI.

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

I don't agree.  For instance, try implementing the equivalent of
multimethods without some kind of downcast.  Of course, if a language
supported multimethods from the get-go it would be even nicer, but very few
languages do.  Now, if you're going to argue that wanting multimethods at
all is a sign that you haven't thought through a problem carefully enough,
we'll just have to agree to disagree.  I'm always suspicious of arguments
that start off with "you really don't want to do that", because I can't say
with any certainty what I will want to do or need to do 100% of the time.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: