]> Jacques Garrigue wrote: > From: Alessandro Baretta <alex@baretta.com> >>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 = <some generally useful stuff method m1 = <other generally useful stuff> ... method mn = <other generally useful stuff> end class b = object (self) inherit a as super_a method m = <specific stuff>; super_a # m method m1 = <specific stuff>; super_a # m1 ... method mn = <specific stuff>; 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 <class> as <identifier> }* ... 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