[squeak-dev] Re: On traits composition

Colin Putney cputney at wiresong.ca
Wed Dec 9 05:49:28 UTC 2009


On 8-Dec-09, at 12:27 PM, Andreas Raab wrote:

> Colin Putney wrote:
>> 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.
>
> 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.


Well, going back to the original Traits paper[1]:

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."

And later in the same section (note the third rule):

Trait composition respects the following three rules:

• Methods defined in the class take precedence over trait methods.  
This allows the glue methods defined
in a class to override methods with the same name provided by the used  
traits.

• Flattening property. A non-overridden method in a trait has the  
same semantics as if it were implemented
directly in the class using the trait.

• Composition order is irrelevant. All the traits have the same  
precedence, and hence conflicting trait
methods must be explicitly disambiguated.

See also section 3.1.3, where Definition 8, proposition 1 includes a  
proof that Trait composition is both associative and commutative.

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.

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.

Colin


[1] http://scg.unibe.ch/archive/phd/schaerli-phd.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091208/28b9ffb2/attachment.htm


More information about the Squeak-dev mailing list