sorry I'm travelling.
The key difference between mixin like approaches and traits is that  
with traits the composer is in control.
There is an automatic conflict resolution but it is explicit in  
traits. With mixin the linearisation is implicit and often out
of control. For state we choose that to avoid merging of attributes  
having the same names, but this is not essential.

Some thoughts about our recent research:
We worked on stateful traits but I do not like what we did. I would  
like to revisit that soon with something much simpler. Roel is  
presenting freezable traits (to control early bindness of methods),  
but the semantics is too complex may be a ruby one is better.After  
done all that I realized that freezable traits is far too complex. So  
we learned something: traits version 1 are cool.
Traits have alias (to give a different name to a method) but may be  
deep renaming (as in Eiffel) would be better (but implementation
would be more complex).

Stef

On 22 oct. 07, at 22:37, Andreas Raab wrote:

> Out of curiosity, what is the difference between Ruby's modules and  
> traits? They strike me as extremely similar, but not being the  
> local Ruby guru I might overlook some implications. As far as I  
> understand it both allow "grouping of methods" (aka: include  
> statements) and both disallow state (in Ruby's case simply because  
> state access is always a dynamic attribute lookup). So what's the  
> difference?
>
> Cheers,
>   - Andreas
>
> stephane ducasse wrote:
>>> Quelques propos (récents) de matz (Yukihiro Matsumoto) à propos
>>> des Traits :
>>>
>>> - "Too bad I didn't know about traits when I designed Ruby."
>>>
>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/274227
>>>
>>> - "If I knew traits before designing Ruby, I'd have chosen traits  
>>> over
>>> modules.  But that's the life."
>>>
>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/274242
>> this is why I will try to find some times to polish traits in squeak
>> stef
>
>
>