caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Michael Vanier <mvanier@cs.caltech.edu>
To: Francois.Pottier@inria.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] a design problem requiring downcasting? (long)
Date: Fri, 27 Sep 2002 03:16:34 -0700	[thread overview]
Message-ID: <200209271016.g8RAGYa27211@orchestra.cs.caltech.edu> (raw)
In-Reply-To: <20020927092023.A32079@pauillac.inria.fr> (message from Francois Pottier on Fri, 27 Sep 2002 09:20:23 +0200)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]


First off, thanks very much to all who have responded to my questions.  I
will have to spend the next few days trying to decipher your solutions.  I
anticipate it will be difficult, but interesting ;-)

As to how I know what to do: the short answer is that I just do because I
set up the simulation.  All simulation objects will be subclasses of a base
simulation object class (let's call it "sim_object"), and I want the array
to be able to store any simulation object whatsoever.  Thus, the type of
the array has to be "array of sim_object" (assuming a pure OO approach,
which is not mandatory).  Fine so far.  Now let's go further and assume
that the sim_object class has a method "my_method".  Then given an array
element, standard OO single-dispatch polymorphism would allow you to access
the version of this method for the array element's true class (which is a
subclass of sim_object) when you invoke obj1#my_method.  So if my_method
didn't take any arguments you'd be done.  But here it takes one argument
(obj2), which is also a sim_object or one of its subclasses.  The problem
is, what it does with this argument depends strongly on what subclass it
gets.  Some subclasses it would just reject (throwing an exception).  With
others, it would do some processing.  Therefore, ideally what I'd like is
either:

1) multiple dispatch polymorphism (dispatching on the types of both obj1
   and obj2).  This is the most elegant approach, but almost no languages
   support this (I think because it's very hard to implement efficiently).

2) a way to do a typecase on obj2 to determine which subclass of sim_object
   it is, so I can do the right thing.

Now, the usual way these simulations are set up is that you create obj1,
add it to the array (actually it's not an array but more like a tree
structure, but never mind), then create obj2, add it to the array, and
immediately invoke "obj1#my_method obj2".  The "my_method" call actually
is part of the simulation setup code.  So you know that obj2 is of the
appropriate subclass when you write the code.  In java I believe the
standard approach is to use instanceof and downcasting, but maybe this can
be achieved in a better way using patterns or one of the functional
approaches that have been proposed.

Incidentally, I very much doubt whether I'll ever need more than double
dispatch for this application (no triple+ dispatch, thank you very much).

Thanks again for all the input,

Mike




> Date: Fri, 27 Sep 2002 09:20:23 +0200
> From: Francois Pottier <francois.pottier@inria.fr>
> 
> Hi,
> 
> > With alternative (1), to do the method call above you would need downcasting
> > e.g. in pseudo-ocaml:
> > 
> >   let obj1 = array.(0) as class1 in
> >   let obj2 = array.(1) as class2 in
> >   obj1#my_method obj2
> > 
> > with the cast raising an exception if it fails.  No problem.
> 
> There is something you haven't explained here. How, given the array
> indices 0 and 1, do you know that the appropriate classes are class1
> and class2? How do map from an index back to the expected class? If
> we knew this, perhaps we would able to give better advice.
> 
> -- 
> François Pottier
> Francois.Pottier@inria.fr
> http://pauillac.inria.fr/~fpottier/
> 
-------------------
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:[~2002-09-27 14:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-26  9:01 Michael Vanier
2002-09-26 14:32 ` Remi VANICAT
2002-09-26 15:19 ` nadji
2002-09-26 15:27   ` Remi VANICAT
2002-09-26 15:55     ` nadji
2002-09-26 15:53 ` Jeffrey Palmer
2002-09-26 16:35 ` Oleg
2002-09-26 17:47 ` brogoff
2002-09-26 19:14 ` Fred Smith
2002-09-27 17:01   ` Tim Freeman
2002-09-26 22:46 ` Alessandro Baretta
2002-09-27  7:20 ` Francois Pottier
2002-09-27 10:16   ` Michael Vanier [this message]
2002-09-29 22:59     ` Alessandro Baretta
2002-09-30  7:09       ` Michael Vanier
2002-09-30  9:54         ` Alessandro Baretta

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=200209271016.g8RAGYa27211@orchestra.cs.caltech.edu \
    --to=mvanier@cs.caltech.edu \
    --cc=Francois.Pottier@inria.fr \
    --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).