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

I assume that you mean this other structure is or could be built of 
ordinary Smalltalk and for such cases Traits is used only as a 
"thinking-help" in a two-tiered development process:

1) Do it with Traits
2) At many places, traits are indications that you have done something 
wrong. Do it differently (without using traits).

Interesting, but a bit indirect :) and as I said perhaps people are not 
aware of the second part. Thinking abstractly I am really unsure if this 
   is an argument in favor of Traits, it looks like being able to use a 
trait may put you on the wrong trail.

Regards,
Martin