<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 8-Dec-09, at 12:27 PM, Andreas Raab wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Colin Putney wrote:<br><blockquote type="cite">One of the defining features of Traits is that composition is commutative. The order doesn't matter because the composition of any two traits is an XOR operation on the methods that each Trait defines. Any method that is defined in both the Traits does not show up in the composition.<br></blockquote><br>Wh...wh...wh..what? "any method that is defined in both traits does not show up in the composition"??? Can you provide any evidence for this? That is not my understanding of neither intention nor reality.<br></div></blockquote></div><div><br></div><div>Well, going back to the original Traits paper[1]:</div><div><br></div><div>Section 3.1, which introduces Traits, says, "Traits bear a superficial resemblance to mixins, with several important differences. Several traits can be applied to a class in a single operation, whereas mixins must be applied one at a time. Trait composition is unordered, thus avoiding problems due to linearization of mixins." </div><div><br></div><div>And later in the same section (note the third rule):</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><font class="Apple-style-span" face="Times" size="3"><span class="Apple-style-span" style="font-size: 12px;">Trait composition respects the following three rules: <br><br></span></font></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><font class="Apple-style-span" face="Times" size="3"><span class="Apple-style-span" style="font-size: 12px;">• Methods defined in the class take precedence over trait methods. This allows the glue methods defined <br>in a class to override methods with the same name provided by the used traits. <br><br></span></font></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><font class="Apple-style-span" face="Times" size="3"><span class="Apple-style-span" style="font-size: 12px;">• Flattening property. A non-overridden method in a trait has the same semantics as if it were implemented <br>directly in the class using the trait. <br><br></span></font></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><font class="Apple-style-span" face="Times" size="3"><span class="Apple-style-span" style="font-size: 12px;">• Composition order is irrelevant. All the traits have the same precedence, and hence conflicting trait <br>methods must be explicitly disambiguated. </span></font></blockquote><div> <br></div><div>See also section 3.1.3, where Definition 8, proposition 1 includes a proof that Trait composition is both associative and commutative. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Colin</div><div><br></div><div><br></div><div>[1] <a href="http://scg.unibe.ch/archive/phd/schaerli-phd.pdf">http://scg.unibe.ch/archive/phd/schaerli-phd.pdf</a></div></body></html>