Eliot Miranda wrote:
> but as an error.  There isn't any way of removing a method.  Were foo 
> inherited from some superclass then unless the error method is generated 
> there would be no indication that there was a conflict between the two 
> traits defining foo.  So traitError is a more specific version of 
> shouldNotImplement.
> 
> foo
>     self shouldNotImplement
> 
> is not as descriptive (it could be expressing the class author's intent) as
> 
> foo
>     self traitConflict
> 
> but both are equivalent; they raise run-time errors saying "this method 
> shouldn't be here".  That's not the same as saying the conflict shows up 
> as a useful method; it doesn't.

My understanding was that #traitConflict is essentially equivalent to a 
"self shouldBeImplemented", i.e., an indicator that manual work is 
needed to resolve the conflict. That's why I'm saying that "last one 
wins" would be a useful default more often than raising an error. See my 
previous comment - the idea that traits are (by design) intended to 
represent an XOR of methods is complete news to me. It'd be good if 
someone could back this up.

BTW, I really don't think there is much difference between mixins and 
traits; all forms of MI are fairly equivalent.

Cheers,
   - Andreas