Colin Putney wrote:
> Well, going back to the original Traits paper[1]:

Thanks for the quotes.

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

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

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

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)

Cheers,
   - Andreas