From: Michael Vanier <mvanier@cs.caltech.edu>
To: bhurt@spnz.org
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Re: OCAML Downcasting?
Date: Tue, 21 Sep 2004 15:06:21 -0700 (PDT) [thread overview]
Message-ID: <20040921220621.92EA99BD95@orchestra.cs.caltech.edu> (raw)
In-Reply-To: <Pine.LNX.4.44.0409211619370.5809-100000@localhost.localdomain> (message from Brian Hurt on Tue, 21 Sep 2004 16:38:25 -0500 (CDT))
> 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
next prev parent reply other threads:[~2004-09-21 22:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ci7tcf$qqf$1@wolfberry.srv.cs.cmu.edu>
[not found] ` <ci9ggm$i6p$1@wolfberry.srv.cs.cmu.edu>
2004-09-21 8:03 ` Jacques GARRIGUE
2004-09-21 8:43 ` Damien Pous
2004-09-21 9:15 ` Jacques GARRIGUE
2004-09-21 9:29 ` skaller
2004-09-21 9:49 ` Jacques GARRIGUE
2004-09-21 9:34 ` Stefano Zacchiroli
2004-09-21 9:56 ` Jacques GARRIGUE
2004-09-21 19:27 ` Michael Vanier
2004-09-21 21:38 ` Brian Hurt
2004-09-21 22:06 ` Michael Vanier [this message]
2004-09-21 22:32 ` Brian Hurt
2004-09-22 1:04 ` skaller
2004-09-21 22:20 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 2:26 ` skaller
2004-09-22 6:31 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 9:03 ` sejourne_kevin
2004-09-22 10:29 ` Richard Jones
2004-09-22 18:39 ` Brian Hurt
2004-09-22 10:50 ` skaller
2004-09-22 12:03 ` Alain Frisch
2004-09-22 12:50 ` Cláudio Valente
2004-09-22 13:15 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 15:50 ` skaller
2004-09-22 18:42 ` Brian Hurt
2004-09-22 18:44 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 19:18 ` Brian Hurt
2004-09-22 0:50 ` skaller
2004-09-22 1:30 ` Jacques GARRIGUE
2004-09-22 2:59 ` skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040921220621.92EA99BD95@orchestra.cs.caltech.edu \
--to=mvanier@cs.caltech.edu \
--cc=bhurt@spnz.org \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox