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 LAA06773; Tue, 16 Jul 2002 11:21:43 +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 LAA06736 for ; Tue, 16 Jul 2002 11:21:42 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com (r-mi214-6a44.tin.it [62.211.4.44]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6G9Lfb29966 for ; Tue, 16 Jul 2002 11:21:41 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id E625E2724F; Tue, 16 Jul 2002 11:28:44 +0200 (CEST) Message-ID: <3D33E74C.6050307@baretta.com> Date: Tue, 16 Jul 2002 11:28:44 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: it, en MIME-Version: 1.0 To: Jacques Garrigue , Ocaml Subject: Re: [Caml-list] Recovering masked methods References: <3D335729.3020307@baretta.com> <20020716101520Q.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue wrote: > From: Alessandro Baretta >>Now I would like to define a third class, inheriting from b. >> I need this class to be able to access the definition of >>method m from class a, otherwise I would have to use "copy & >>paste", which is contrary to my programmer's ethics. > > > You don't need to be too ethical about that. > What's so great about strong typing, is that it makes copy-paste work! :-) > And you can always write > > let a_m = 1 > class a = ... method m = a_m .. This is not viable. The toy code I have shown here does not provide any real functionality, but in the real application you have to imagine the following situation: class a = object (self) method m = ... method mn = end class b = object (self) inherit a as super_a method m = ; super_a # m method m1 = ; super_a # m1 ... method mn = ; super_a # mn end class small_variant_of_b = object (self) inherit b as super_b method m = super_b # super_a # m (* All the specific stuff in method m is not needed *) (* Yet, all other methods must be inherited from b *) end Without the above notation, I could only think of copying the code of method m out of class a and pasting it into class small_variant_of_b, but this makes maintainance a mess. And I am working on a production class system. No good. However, I did not consider the following idea, which is not bad indeed. In the absence of the notation I described above, or of an equivalent one, I'll do as you propose here. > If you want to stay indide the object, you can also save the old > method to a private one: > > class b = ... method private a_m = super_a#m ... > > >>Ideally, I would like to write >> >>class c = >>object (self) >> inherit b as super_b >> >> method m = >> (* some_stuff *) >> super_b # super_a # m >>end >> >>Presently, this is not allowed. Is there any specific reason >>for this? Could such a feature be implemented in the future? > > > OK, you want something like C++'s qualified calls? > There's no project to do that. Methods do not exist independently of > their class. > Another approach would be to provide views, as described by Jerome > Vouillon. That is, an object could keep some extra sets of methods in > an abstract way. But there's not project to implement that either. You are getting too technical for me. I'm not a compiler guru, only a user, so I'm not sure what could or should be done. Let me propose a syntax which might make things clearer. class a = object ... end class b = object inherit a ... end class c = object inherit a as super_a through b as super_b { through as }* ... end Let me call this syntax "explicit inheritance hierarchy relation". This syntax is only viable if we assume that extending a working class library never requires to *insert* a class between two classes in a relation of inheritance. Such extensions would break the above code. I don't believe this limitation would have any real impact on the the usability of the language or of this extension. > Yet, it's not even clear such an ancestor call would make sense in > general. > Could you give some more compelling example requiring such a feature? I a method m in class b can call a method x in super_a (which is class a), and a method m' in class b' can call a method m in super_b (which is class b), then, by transitity, a method in class b' can call a method x in super_a. All we need is some syntactic sugar to make this happen "automagically". But I would not rely on CamlP4 for this: the syntax extension would not have a local impact, so we need help from the compiler. Let me know what you think. Alex ------------------- 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