On 26 févr. 05, at 2:37, Ned Konz wrote:

> On Thursday 24 February 2005 1:46 pm, Martin Wirblat wrote:
>> Furthermore this Collection hierarchy is already there! It is my
>> assumption, that unless I program a similar hierarchical monster like
>> Collections I don't gain much from Traits. I even fear that Traits may
>> lure into programming hierarchical, where a flat structure combined 
>> with
>> the normal composition would be the better way to go.
>
> Actually, I think that the analysis that Traits does can help with 
> converting
> an overly-inherited (whether by Traits mixins or by straight 
> inheritance)
> structure into one that is more like a group of collaborating objects.
>
> My reasoning is that the individual traits would be exactly the chunks 
> of
> behavior that one could (and in many cases should) factor out into a 
> separate
> object.
>
> So in some sense, seeing the traits serves as a reminder that you have 
> an
> object with multiple responsibilities, and that some of those
> responsibilities might be better expressed using another structure.

true this is one intention. Traits are interfaces with method 
definition so
they are the basic bricks of building class out of higher abstractions 
than methods.

Stef