My point of view is that traits helping produce more clear protocol
and avoid #shouldNotImplement stubs. And with delegation you tend to
have heavier protocols.
But i think that this mainly depends on developer. Both approaches,
when misused can lead to horrible results :)

In my asm-generator i found a good use of traits - like an extension
mechanism which can be applied to any class to override some basic
behavior. In my case, by adding a trait to some class,  i'm overriding
methods which used for compiling instance side methods, so i can
replace and/or extent parser or compiler features only for particular
class(es)  without modifying parser/compiler globally.
Also, i don't need to change inheritance chain in classes, where i
adding traits.


On 03/09/07, Blake <blake at kingdomrpg.com> wrote:
> On Mon, 03 Sep 2007 02:22:17 -0700, Andreas Raab <andreas.raab at gmx.de>
> wrote:
>
> [a whole bunch of stuff]
>
> I actually penned a more detailed reply but I don't think it would, for
> the most part, bear fruit. I agree with a lot of what you said, and
> disagree with some other parts. My only purpose in bringing up traits is
> that the collection example (while "toy") at least makes a persuasive
> arguments, especially when compared with nothing (pipes-enhanced code).
>
> This, however, got me thinking:
>
> > I'm looking forward to it. In my experience the best way to deal with
> > complexity is to factor it into objects, not traits, and use trivial
> > delegation methods where necessary.
>
> ...since (as a long-time Delphi programmer) I'm working backwards from
> that viewpoint. Delegation has some great applicability and it can also
> enable some terrible design. But if delegation really can serve the same
> purpose as traits, it should be possible to refactor the collections class
> using delegation and receive most of the benefits without most of the
> complexity. Yes?
>
>         ===Blake===
>
>


-- 
Best regards,
Igor Stasenko AKA sig.