[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Brian Hurt <bhurt@s...> |
| Subject: | Re: [Caml-list] Re: OCAML Downcasting? |
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