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