Hi Alex,

on Mon, 26 Jun 2006 11:45:56 +0200, you wrote:
> Klaus wrote:
>> You're right and as many times before I appreciate your expertise!  
>> There is indeed a gap between the time of setting the super class  
>> reference (bytecode i-1) and when the VM starts using it (bytecode i 
>> +0). But from there on, method lookup and method activation is atomic.
>
> Yes, method lookup and method activation are atomic. But I had in mind  
> if a super call does a Processor yield. The method containing the super  
> invocation contains the ref of the second super class. But humm...  
> perhaps it does not matter after all.

Right. The result of a method lookup is stored in the MethodContext,  
regardless of how the method was found (from cache or by traversing the  
superclass hierarchy). So no problem with Processor yield - storing the  
methodClass field followed by a super send can be made two adjacent  
bytecodes. And the possible aio (incl. Processor yield) would involve  
scheduling only at the message send boundary (right after  
activateNewMethod).

But again, I think that a static (compile-time) value for the methodClass  
field (a class which actually points to the desired superclass) is  
sufficient for MI.

> If a method has to be lookup in other classes, then if will always have  
> to be. I have to think a bit more...

:) Hint: after method activation the VM no longer looks to the caller's  
site (except when returning, of course).

> But my general feeling is that multiple inheritance is complicated. Much  
> more than traits.

Yes, the flatness (of traits) is what makes traits so uncomplicated.  
Having, OTHO, always the choice of which parent to lookup next needs a  
whole lot of discipline (seems to shine through between the lines in "The  
Power of Simplicity", which wouldn't have been possible without rigid  
discipline).

I agree that MI can have a disturbing and even a catastrophic downside,  
especially when combined with dynamic lookup.

> I was visiting the team of Bertrand Meyer in Zürich last week. I really  
> wanted to understand the difference between stateless traits, stateful  
> traits and multiple inheritance à la Eiffel. It seems that everything  
> that can be done with state(less|ful) traits can be done in Eiffel. The  
> only difference is about complexity to achieve a particular behavior.

Hey! Thank you for mentioning. I'd love to learn about that difference  
 from your point of view. When are you in Switzerland next time? Drop me an  
email.

> With traits the flattening property makes the whole story simple, while  
> in Eiffel the static type system makes it horribly complicated.
...
>
> Not trivial to determine it without being expert in Eiffel...

I'm not an expert in Eiffel but will take the opportunity and work through  
your examples, just for the fun of it. Thank you.

/Klaus