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