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 EAA07851; Wed, 22 Sep 2004 04:59:20 +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 EAA07871 for ; Wed, 22 Sep 2004 04:59:18 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i8M2xFuq023289 for ; Wed, 22 Sep 2004 04:59:17 +0200 Received: from [192.168.1.200] (ppp202-133.lns1.syd3.internode.on.net [203.122.202.133]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i8M2xAOU070551 for ; Wed, 22 Sep 2004 12:29:12 +0930 (CST) Subject: Re: [Caml-list] Re: OCAML Downcasting? From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list In-Reply-To: <20040922.103031.29661243.garrigue@kurims.kyoto-u.ac.jp> References: <20040921.170339.118021840.garrigue@kurims.kyoto-u.ac.jp> <20040921192719.92B859BD95@orchestra.cs.caltech.edu> <20040922.103031.29661243.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1095821949.2580.1046.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 Sep 2004 12:59:10 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4150EA83.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 downcasting:01 sourceforge:01 2004:99 jacques:01 abstractions:01 subtyping:01 enforced:01 enforcement:99 separates:01 enforcement:99 deliberate:99 9660:01 glebe:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2004-09-22 at 11:30, Jacques GARRIGUE wrote: > From an implementation point of view, java interfaces are just a hack > to work around the absence of multiple inheritance. I don't think this is quite right. In C++ you can use 'mixin' abstract classes, however the basic rule is that you do all the mixing with the abstractions, providing subtyping, and then any mixing you do in providing an implementation is regarded as 'implementation inheritance' which you should represent using private bases. However this last rule isn't enforced. Java provides two ways to enhance enforcement: it separates the notion of the abstract class from the concrete implementation, and it provides 'final' classes. Thus, the idea isn't entirely a workaround for lack of multiple inheritance, but instead a refinement of more general and less secure C++ technology, which provides a bit more enforcement. I.e: the separation is deliberate and based on some concept of enforcement of constraints, rather a workaround for a deficiency. -- 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