[
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: | 2004-09-21 (21:29) |
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