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 AAA24598; Fri, 27 Sep 2002 00:37:21 +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 AAA24596 for ; Fri, 27 Sep 2002 00:37:20 +0200 (MET DST) Received: from athlon.baretta.com (host136-68.pool80116.interbusiness.it [80.116.68.136]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g8QMbJ509397 for ; Fri, 27 Sep 2002 00:37:19 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 7988227399; Fri, 27 Sep 2002 00:46:59 +0200 (CEST) Message-ID: <3D938E63.6000909@baretta.com> Date: Fri, 27 Sep 2002 00:46:59 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: it, en MIME-Version: 1.0 To: Michael Vanier Cc: caml-list@inria.fr Subject: Re: [Caml-list] a design problem requiring downcasting? (long) References: <200209260901.g8Q910t03459@orchestra.cs.caltech.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Michael Vanier wrote: > I've run into a design problem that I think requires downcasting, and I > wanted to see if anyone on the list has any ideas about an alternative > approach, since AFAIK downcasting is impossible in the current ocaml object > system (at least without nasty Obj.magic hacks). I'll try to simplify the > problem as much as possible, but this is still pretty long. > > Scratch... scratch... Hmmm... I'm not really sure why you would want to use downcasts in your problem. I have been taught, as a general rule, that a downcast is (usually) a bug in the design and often also a bug in the implementation. Downcasting in O'Caml is only useful when you have classes with *different* class types but sharing some common ancestor. Then you can keep a reference to the an object of the ancestor class and downcast it selectively to recover the methods added by inheriting classes. But, then again, if your design requires to keep a reference to a generic object, you are explicitly throwing out type information: in O'Caml upcasts are explicit, so you know *exactly* where you are throwing away type information. If you throw out type information and subsequently need a downcast to recover it, then you are probably working with a wrong abstraction somewhere in your analysis. If I were you, I'd consider using a virtual base class as a common ancestor. Such a class would have to define all the public methods that might be called on any object. If a given method is truly meaningless within a specific class, you can always define it as raising a Meaningless_method exception, or something similar. But then you'd better make sure that your algorithm is correct, or it will die miserably with uncaught exceptions. This is very much like downcasting, but it aids you in figuring out exactly what methods are creating the trouble. In my last project, I noticed that most typing problems with classes were due to refinements of a base class being unified with their ancestor where this was not meaningful. It turned out that I could always solve this typing problem by isolating newly created objects of the inheriting classes, calling what additional methods the iheriting class defined in the appropriate order, and upcasting to the base class. The new object, thus initialized, could then be correctly type-restricted, without ever needing to recover the type information thrown away. This strategy might not necessarily be appicable to your case, but I consider it, at least. It might save you a lot of hell. Remember: "If God wanted us to downcast, he would have given us RTTI." Alex ------------------- 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