[
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 (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 <bhurt@spnz.org> > Cc: garrigue@kurims.kyoto-u.ac.jp, <caml-list@inria.fr> > > 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. Mike ------------------- 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