Re: [Caml-list] a design problem requiring downcasting? (long)

[Jeffrey Palmer <jeffrey.palmer@acm.org>]

On Thursday 26 September 2002 4:01 am, Michael Vanier wrote:
> It turns out that the design of the core simulator doesn't pose any
> real problems.  However, part of the simulation infrastructure is
> very difficult to achieve without having a way of downcasting
> (casting from a supertype to a subtype).  It can be done, but the
> design becomes extremely non-modular.  The issue is that these
> simulations can contain tens of thousands of simulation objects which
> can invoke method calls on each other.  These are actually binary
> method calls e.g.
>
>   obj1#my_method obj2
>
> where "obj2" has to be of a specific class type (in actuality, it
> will be an interface type).  These method calls are highly dependent
> on the specific types of the objects.  If you create the objects like
> this:
>

I'm assuming that each object in the simulation has the ability send a 
"class-specific" message to all of the other objects in the system. (If 
this isn't correct, then please let me know). With this in mind, 
subclassing gets you very little, as most methods aren't applicable (in 
good OO design) at the abstract class level.

I can think of at least three options that can get you what you want 
without downcasting:

1) Use double-dispatch, along the lines of the Visitor pattern. You 
could implement an abstract Visitor class that defaults to no operation 
for most of the classes you'd like to cover, and then subclass 
appropriately to handle the cases that are required for a specific 
method/class combination. I've used this technique extensively (in 
Java), and it's worked well. (You might have to combine this with a 
variant of #2).

2) The problem you're having is because the method "message" isn't smart 
enough to know what it applies to. As they say, abstraction solves most 
problems, so perhaps you could implement a Message class that would be 
passed from object to object (you might not really need objects, at 
that point). You could make some clever use of HOFs and tags to allow 
each object to implement a "does this message apply to me" test, and if 
so it executes it.

3) Since you're already storing all of the objects in an array, why not 
use a subclass-specific storage and pass class-specific messages only 
to that collection. This doesn't handle shared methods so well 
(duplicate storage), but it is an option. You could then implement a 
message dispatcher that knows which collection to use for various 
message types.

Anyway, those are three that I came up with off the top of my head. 
Perhaps I've misunderstood your problem, though. If so, please let me 
know and I'd be happy to try to come up with some more options.

	- jeff

-- 
The river is moving.
The blackbird must be flying.

-------------------
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