Blake wrote:
> On Mon, 03 Sep 2007 00:19:29 -0700, Andreas Raab <andreas.raab at gmx.de> 
> wrote:
>> Do you have an actual example of how the code is cleaner or are you 
>> simply repeating what other people tell you? I've been looking for 
>> good examples for traits for a couple of years now but it seems that 
>> when things go beyond the toy examples presented in the papers traits 
>> create more complexity than they help to address.
> 
> I know you feel that way and I'm not in a position to make a complete 
> argument one way or the other yet. But I =would= maintain that the 
> removal of duplicate code and the segregation of responsibilities into 
> meaningful compartments results in a set of collection classes that is 
> cleaner and actually easier to apprehend.

Yes, abstractly speaking that is so. However, that removal of duplicate 
code doesn't come for free - it comes with the cost of extra entities 
that a user needs to understand and which makes for more complexity that 
one has to deal with. It comes with multiple inheritance hierarchies 
that users need to understand which makes for more complexity. It comes 
with required, provided, renamed, and excluded methods that a user needs 
to keep in mind and makes for more complexity.

If it were *only* the removal of duplicate code, this would be hard to 
argue with. But it isn't; traits make a very complex set of tradeoffs in 
the hope to do more good than bad. However, practical examples seem to 
indicate that the net result is more complexity rather than less. See 
for example:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119295.html

> Maybe I'll come out of my current experiments with the same opinion you 
> have, I don't know. But the competing ideas I've tried have not done 
> anything for me. And I'll share my results but of course I can't 
> guarantee you won't think they're toy.

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.

>>> It's reasonable to ask for some evidence.
>>
>> Indeed. Correcting mistakes is reasonable too, but both usually don't 
>> happen.
> 
> I'm not sure if this is a cryptic reference to believing that traits is 
> a mistake and should be removed but if so, it would seem to be easy to 
> undo relative to the scope of the issues being tackled.

It is a cryptic reference to people who without having even looked at 
traits repeat all the "benefits" that they have been told (which doesn't 
just apply to you). It's quite sad actually. If more people would be 
actually looking at traits we might even have an interesting discussion. 
Without it, you get these "traits are great, of course I have never used 
them, but I'm sure with them everything is better" arguments.

Cheers,
   - Andreas