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 EAA16893; Wed, 13 Oct 2004 04:27:17 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA17077 for ; Wed, 13 Oct 2004 04:27:15 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9D2RDpK022104 for ; Wed, 13 Oct 2004 04:27:14 +0200 Received: from [192.168.1.200] (ppp202-150.lns1.syd3.internode.on.net [203.122.202.150]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i9D2R84Y023437; Wed, 13 Oct 2004 11:57:08 +0930 (CST) Subject: Re: [Caml-list] Narrowing class's public interface From: skaller Reply-To: skaller@users.sourceforge.net To: John Prevost Cc: caml-list In-Reply-To: References: <200410131116.12485.edgin@slingshot.co.nz> <20041013.094903.08315159.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1097634426.19740.152.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 13 Oct 2004 12:27:07 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 416C9281.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 narrowing:01 class's:01 sourceforge:01 2004:99 prevost:01 gaussian:01 gaussian:01 'real:01 covariant:01 abstraction:01 quadratic:01 subtypes:01 9660:01 glebe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2004-10-13 at 11:43, John Prevost wrote: > Even though we inherit float_random_variable in the type for class > gaussian, gaussian is not, and never will be, a subtype of > float_random_variable. The trouble is that we have a binary method > here. Indeed. More generally, objects require invariant (or contravariant) method arguments, but almost all 'real world' problems .. and mathematics ones in particular .. require covariant arguments, binary operators being a special case of that. Hence OO is useless as a general paradigm. It's a useful technique in special cases .. in particular you get dynamic dispatch. For example you can use OO abstraction for device drivers because the read and write methods only handle a *fixed* data type (characters). Don't even both trying to make the character type polymorphic because the theory says it can't be done. The reason is also easy to see, as John Provost described, but another view of the same thing: you'd need one method for every driver kind/character kind combination. In other words the number of methods needed is quadratic in the subtypes, but OO only supports linear -- you can supply a new method for each derived 'main object' type .. which is why the method arguments can't also be polymorphic. -- 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