<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 12:46 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Colin Putney wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, going back to the original Traits paper[1]:<br>
</blockquote>
<br></div>
Thanks for the quotes.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And later in the same section (note the third rule):<br>
<br>
Trait composition respects the following three rules: <br>
• Methods defined in the class take precedence over trait methods.<br>
This allows the glue methods defined in a class to override methods with the same name provided by the<br>
used traits. <br>
• Flattening property. A non-overridden method in a trait has the<br>
same semantics as if it were implemented directly in the class using the trait. <br>
• Composition order is irrelevant. All the traits have the same<br>
precedence, and hence conflicting trait methods must be explicitly disambiguated.<br>
</blockquote>
<br></div>
Indeed. It was this talk about "explicit disambiguation" (which I recalled from other discussions) which led me to understand that "self traitConflict" is to be interpreted as "please be explicit about which of the methods you'd like to use" instead of "this method ain't here".<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't see any references to XOR operations, so that must have come from some other discussion of Traits. (I'm pretty sure I didn't make that up from thin air!) Instead the paper talks about explicit conflicts which have to be resolved, consistent with the #traitConflict methods the Squeak implementation creates. <br>
So I guess "does not show up in the composition" is wrong. It would be better to say "creates a conflict that must be explicitly resolved." But still, I think it's fair to say that this is one of the defining features of Traits, in contrast with Mixins, which do follow a "last one wins" method of resolving conflicts. <br>
</blockquote>
<br></div>
I suppose. I find it pretty useless but then again, I find MI in general pretty useless so there isn't much difference to me :-) (but rest assured that I'll leave the behavior alone for those people who care)<br>
</blockquote><div><br></div><div>I was so enthused about the Borning-Ingalls multiple inheritance implementation that I spent a lot of time in the BrouHaHa variant of Smalltalk-80 V2 fixing bugs (like making file-outs and class redefinitions work without regenerating spurious conflict methods), and providing an extension to the class definition to specify the resolution of conflicts (*). But after all that work there were precisely three instances of MI in the system; I made ReadWriteStream inherit multiply from ReadStream and WriteStream, DateAndTime inherit multiply from Date and Time and, of course, Queen inherited multiply from Rook and Bishop (**) :)</div>
<div><br></div><div><br></div><div>(*) P.S. e.g. you could say </div><div><div>Class named: #ReadWriteStream</div><div> superclasses: 'WriteStream ReadStream '</div><div> inheritanceAnnotation: 'WriteStream overrides: ReadStream'</div>
<div> instanceVariableNames: ''</div><div> classVariableNames: ''</div><div> category: 'Collections-Streams'!</div><div><br></div><div><br></div><div>(**) P.P.S. Queen's MI was entirely spurious. The only method that Bishop and Rook defined was isPotentialMoveTo: position in: board. Since it was faster to reimplement isPotentialMoveTo:in: directly than as ^(Rook. isPotentialMoveTo: position in: board) or: [Bishop isPotentialMoveTo: position in: board] it didn't actually inherit anything from them.</div>
<div><br></div><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
<br>
</font></blockquote></div><br>