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 JAA13954; Sat, 14 Aug 2004 09:39:08 +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 JAA12657 for ; Sat, 14 Aug 2004 09:39:07 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i7E7d4RM006604 for ; Sat, 14 Aug 2004 09:39:05 +0200 Received: from [192.168.1.200] (ppp197-3.lns1.syd2.internode.on.net [203.122.197.3]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i7E7d0HY089636; Sat, 14 Aug 2004 17:09:00 +0930 (CST) Subject: Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass From: skaller Reply-To: skaller@users.sourceforge.net To: "chris.danx" Cc: Caml Mailing List In-Reply-To: <411D56EC.2070301@ntlworld.com> References: <411D56EC.2070301@ntlworld.com> Content-Type: text/plain Message-Id: <1092469137.29139.564.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 14 Aug 2004 17:38:57 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 411DC198.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 overriding:01 sourceforge:01 2004:99 abstraction:01 abstraction:01 lexically:01 scattered:01 lexically:01 9660:01 glebe:01 unify:01 unify:01 chris:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2004-08-14 at 10:03, chris.danx wrote: > Perhaps a radically different solution is best? I chose an OO solution > so that new classes could be trivially added to the system. There is another kind of solution you might investigate. Instead of trying to unify all your data types using abstraction -- classes provide abstraction -- use summation instead. A summation solution looks like: type obj = [ | `A of a | `B of b * obj | `C of c * obj * obj ] using polymorphic variants. In order to 'do something' with each object, including children, you write a 'visitor' style function: let rec iter x = match x with | `A a -> do_a a | `B (b ,kid) -> do_b b; iter kid | `C (c, k1, k2) -> iter k1; do_c c; iter k2 When you need to add a new object type to this system you have to add the method for handling it, just as in the OO solution. The difference is that the method doesn't go in with the data lexically, but separately in the visitor function. Ocaml will make sure you don't forget. This kind of solution is more flexible than the OO style solution, since you can write many different kinds of 'visitor' style functions without invading your data descriptions. The downside is that the code for each kind is scattered through the program, whereas with classes its localised lexically. Which solution is best depends on how homogenous your object kinds are. If they're all instances of a single abstraction -- use classes. If they're heterogenous objects -- use summation. You can of course mix both solutions together -- abstract what really is abstract, and unify what is not using variants. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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