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 TAA32273; Sat, 14 Aug 2004 19:22:00 +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 TAA30310 for ; Sat, 14 Aug 2004 19:21:59 +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 i7EHLtRM025716 for ; Sat, 14 Aug 2004 19:21:57 +0200 Received: from [192.168.1.200] (ppp197-3.lns1.syd2.internode.on.net [203.122.197.3]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i7EHHE4Y005430; Sun, 15 Aug 2004 02:47:14 +0930 (CST) Subject: Re: Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass From: skaller Reply-To: skaller@users.sourceforge.net To: John Prevost Cc: Caml Mailing List In-Reply-To: References: <411D56EC.2070301@ntlworld.com> <1092469137.29139.564.camel@pelican.wigram> Content-Type: text/plain Message-Id: <1092503833.29139.668.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 15 Aug 2004 03:17:13 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 411E4A33.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 prevost:01 subtyping:01 stupid:01 subtyping:01 subclassing:01 equivalently:01 9660:01 glebe:01 subtype:01 nsw:01 snail:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-08-15 at 02:28, John Prevost wrote: [structural subtyping] > At this point, you may be wondering "Why is O'Caml like this? My stupid answer is "because its correct". The kind of subtyping by subclassing used in Java and C++ is really awkward to use. Basically the problem is, to extend the capabilities of your object heirarchy, you inevitably have to add a new method to a base class, or equivalently derive from an extra base class containing it -- which breaks the principle of encapsulation that is supposedly the foundation of object orientation: such breakage is said to be invasive, and it contravenes the Open/Closed principle (see Meyer). This isn't the case for structural subtyping, where A is a subtype of B simply if it is one -- you don't have to derive A from B -- which might not even exist at the time you write A. This means you can write algorithms that work on sets of classes sharing some properties (such as a collection of methods) AFTER you define the classes without invading the class definitions -- in Java or C++ you'd have to add inheritance specifications to make this work. -- 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