From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C29BFBB91 for ; Sun, 26 Dec 2004 19:20:11 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBQIKBh7005528 for ; Sun, 26 Dec 2004 19:20:11 +0100 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 TAA26892 for ; Sun, 26 Dec 2004 19:20:11 +0100 (MET) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBQIKA7v008865 for ; Sun, 26 Dec 2004 19:20:10 +0100 Received: by wproxy.gmail.com with SMTP id 71so296261wri for ; Sun, 26 Dec 2004 10:20:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YIKFYS0v/tnsnemM42aZxs+Lnkaw5RVq52T3mw9ydTf2bcJKjDU9BuiUZv6UVwseCX8O0fn/GzpVX8d7ERBeXh2iPoRX0DAsT88gcJCibfXstSWwpv+MBlj3mXDPPDJhr2p3ep7qk7KPwTOHWCdb20V2Zi/OXisZour5DFHzXLU= Received: by 10.54.16.71 with SMTP id 71mr68227wrp; Sun, 26 Dec 2004 10:20:09 -0800 (PST) Received: by 10.54.22.70 with HTTP; Sun, 26 Dec 2004 10:20:09 -0800 (PST) Message-ID: Date: Sun, 26 Dec 2004 13:20:09 -0500 From: John Prevost Reply-To: John Prevost To: caml-list@inria.fr Subject: Re: [Caml-list] method name collision ? In-Reply-To: <20041226.075748.126851009.garrigue@math.nagoya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <16845.50460.152550.387582@soggy.deldotd.com> <20041226.075748.126851009.garrigue@math.nagoya-u.ac.jp> X-Miltered: at concorde with ID 41CF00DB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41CF00DA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; prevost:01 prevost:01 caml-list:01 wrote:01 printf:01 printf:01 ocaml:01 subtype:01 model:01 model:01 ...:98 ...:98 embrace:98 idiom:01 inherit:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.0 X-Spam-Level: On Sun, 26 Dec 2004 07:57:48 +0900 (JST), Jacques Garrigue wrote (in response to briand@aracnet.com): > The "as drawable" doesn't mean that the methods are distinct: you can > still call all inherited methods from the outside, and even through > self. > This only allows you to access the old definition of a method, if you > want to extend it incrementally. > > method point ~x ~y = > ... drawable#point ~x ~y ... And just to make sure it's clear, the reason that the type has to match is that *other* methods of the inherited class have to be able to do self#point calls on the new object and work properly. Here's an illustration: ----- class test_1 = object (self) method test a = a + 1 method test_self () = self#test 5 end class test_2 = object inherit test_1 as t1 method test x = Printf.printf "Called with %d\n" x; t1#test x end ----- In this example code, you can see that the inherited methods from test_1, when they make self#... calls, use the overridden methods in test_2. So if test_2 were allowed to change the types of the methods in incompatible ways, there would be a problem. If you *do* want to just use the methods from the other class, I recommend using the following idiom: Instead of this: class broken = object inherit some_other_class as soc method replace_and_change_type = ... (* method pass_through_unchanged is inherited from soc *) end write this: class working = let soc = new some_other_class in object method replace_and_change_type = ... method pass_through_unchanged = soc#pass_through_unchanged end The first one brings inheritance into play--which is important if you want to override methods, but is not neccessary (or sufficient) in OCaml to define a subtype. If, instead, you want to make use of the other class's features in order to implement your class, and pass some methods through unchanged, use the second model. If you need a mixture of both, first extend the base class in order to override its methods (for the base class's internal use, calling self#...), then use the second model to provide a different interface. Finally, I just realized that you could also do this if you want to avoid defining more than one class: class embrace_and_extend = let extended_object = object inherit class_you_want_to_extend method override_something = ... end in object ... provide a different interface ... end It hadn't occurred to me before that the new immediate objects feature allows you to inherit from a class when defining an immediate object. (Although, of course, there is no way to inherit from an immediate object further down the line.) John.