Re: Sketch of multiple inheritance in E

On Mar 10, 2009, at 5:05 PM, Kevin Reid wrote:
> (Fixing diamond inheritance is a little bit tricky, because it means
> that if you have A isa B isa D and A isa C isa D, then B's behavior
> (whether its super-call goes to D or C) has to depend on the existence
> of C, which is not part of B's definition. However, I believe this is
> *possible*, in a safe way, because B has the "self" reference, which
> is the authority on how the composite object should behave.)

Gilad Bracha said that mixin inheritance means that "super" can be  
overridden.  That's true, or at least it's true for linearization  
interpretations of multiple inheritance.

The ultimate authority is the concrete class that is instantiated, in  
this case "A", which can be queried as you describe via the "self"  
reference.  In one way or another, the self reference must specify  
that when B.m does "super", C.m is supposed to respond, when C.m does  
super, D.m is supposed to respond, etc.  If nothing else, such a call  
could be implemented as "self.super_of_m_from_B" and  
"self .super_of_m_from_C".  A then needs to implement all these  
"super" methods.

Figuring out how A should know which method responds to which call...  
looks interesting.  :)  Maybe it can inspect the whole hierarchy above  
it, or maybe it can do something more elegant.

Lex