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 DAA29542; Sat, 21 Aug 2004 03:29:06 +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 DAA29991 for ; Sat, 21 Aug 2004 03:29:01 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i7L1SwRM013361 for ; Sat, 21 Aug 2004 03:29:00 +0200 Received: from [192.168.1.200] (ppp211-206.lns2.syd3.internode.on.net [203.122.211.206]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i7L1Sm4Y090009; Sat, 21 Aug 2004 10:58:49 +0930 (CST) Subject: Re: [Caml-list] Programming with modules From: skaller Reply-To: skaller@users.sourceforge.net To: brogoff Cc: Brian Hurt , Erik de Castro Lopo , caml-list In-Reply-To: References: Content-Type: text/plain Message-Id: <1093051727.29139.1503.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 21 Aug 2004 11:28:48 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4126A55A.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 sourceforge:01 2004:99 brogoff:01 dependencies:01 cyclic:01 dependencies:01 mli:01 recursively:01 conforms:01 abstraction:01 covariant:01 9660:01 glebe:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2004-08-21 at 02:56, brogoff wrote: > There are a few cases where you really do want to support cross module > dependencies, but this seems to be hard to do in a satifactory way. The > issue is made worse IMO by the addition of OO, since class hierarchies, > at least the ones I've used, tend to have more cyclic dependencies. Actually, I have not found that. If you follow the following general technique, the problem is eliminated, except from constructors. First, you have to make a distinct class type for each kind of object. These are all declared together in a single mli file, recursively: I'll call these the abstract class types. Next, define your classes in an arbitrary order. It is important that all variables including arguments to methods use the abstract class types for typing -- NEVER use the concrete class types of the concrete classes you're defining. This obviously ensures that the concrete classes are independent of each other: in particular, the precise concrete representation can be changed as you see fit, provided of course it conforms to its abstract type. There is a further step: constructors. Never export class constructors. They must be wrapped in a normal Ocaml function which returns an abstract class type. Constructors are the *only* difficult thing to get right -- all the rest of this mechanism is obvious and should be done by rote. The reason constructors are tricky is that sometimes a concrete class must be constructed using other concrete classes. In general, if you have a problem ordering the concrete classes and constructors acyclically -- it is a strong indication your design is wrong. OO simply isn't a general paradigm, its form of abstraction is incapable of solving most problems involving 'relationships' since relationships are typically covariant. -- 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