caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


  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;
as well as URLs for NNTP newsgroup(s).