From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA14358; Thu, 26 Sep 2002 17:53:59 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA14343 for ; Thu, 26 Sep 2002 17:53:58 +0200 (MET DST) Received: from boule.etirade.com (12-247-44-244.client.attbi.com [12.247.44.244]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g8QFrv527026 for ; Thu, 26 Sep 2002 17:53:57 +0200 (MET DST) Received: (qmail 29185 invoked from network); 26 Sep 2002 15:53:53 -0000 Received: from unknown (HELO batard.etirade.com) (192.168.1.34) by boule.etirade.com with SMTP; 26 Sep 2002 15:53:53 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Jeffrey Palmer To: Michael Vanier , caml-list@inria.fr Subject: Re: [Caml-list] a design problem requiring downcasting? (long) Date: Thu, 26 Sep 2002 10:53:52 -0500 User-Agent: KMail/1.4.3 References: <200209260901.g8Q910t03459@orchestra.cs.caltech.edu> In-Reply-To: <200209260901.g8Q910t03459@orchestra.cs.caltech.edu> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209261053.52231.jeffrey.palmer@acm.org> Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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=20 "class-specific" message to all of the other objects in the system. (If=20 this isn't correct, then please let me know). With this in mind,=20 subclassing gets you very little, as most methods aren't applicable (in=20 good OO design) at the abstract class level. I can think of at least three options that can get you what you want=20 without downcasting: 1) Use double-dispatch, along the lines of the Visitor pattern. You=20 could implement an abstract Visitor class that defaults to no operation=20 for most of the classes you'd like to cover, and then subclass=20 appropriately to handle the cases that are required for a specific=20 method/class combination. I've used this technique extensively (in=20 Java), and it's worked well. (You might have to combine this with a=20 variant of #2). 2) The problem you're having is because the method "message" isn't smart=20 enough to know what it applies to. As they say, abstraction solves most=20 problems, so perhaps you could implement a Message class that would be=20 passed from object to object (you might not really need objects, at=20 that point). You could make some clever use of HOFs and tags to allow=20 each object to implement a "does this message apply to me" test, and if=20 so it executes it. 3) Since you're already storing all of the objects in an array, why not=20 use a subclass-specific storage and pass class-specific messages only=20 to that collection. This doesn't handle shared methods so well=20 (duplicate storage), but it is an option. You could then implement a=20 message dispatcher that knows which collection to use for various=20 message types. Anyway, those are three that I came up with off the top of my head.=20 Perhaps I've misunderstood your problem, though. If so, please let me=20 know and I'd be happy to try to come up with some more options. =09- jeff --=20 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