Dean_Swan at Mitel.COM wrote:
> My first concern is performance.  Since Traits carry no state, they will 
> need to use accessor methods and message sends are clearly much slower 
> than direct instance variable access.
This is currently true. I wouldn't worry about this too much for the 
following reasons:
1. We have Bryce on our side! the overhead of self sent accessors shall 
soon be reduced to a painful, but fading memory (half kidding, don't 
think he ever promised that, but the essence is true)
2. 95% of code is not performance critical. Of the remaining 5%, I'd bet 
only a part spends significant time accessing variables.
3. We're not converting everything to use accessors now.
4. If we discover that creating a Trait *has* caused a performance 
regression due to this effect, we can override the method in the class, 
trading off code duplication for speed. However at that point, we're 
trading off a tiny bit of duplication for some real speed, as opposed to 
the current situation, where we can't use Traits anywhere, so in lots of 
places we have code duplication that's gaining us nothing
5. If we discover this happens often, there is nothing preventing us 
from optimizing Traits away automatically - always duplicate the method 
into the class, and inline accessors. Make the tools keep this 
CompiledMethod in sync with the original, and prevent us from editing it 
by mistake. At that point this performance concern should be quite dead.

> My second concern is regarding how Traits should/could/would be used.
Nobody claims to really know this. We'll find out soon enough.

>  All 
> of the examples that I have seen so far, including the refactoring of the 
> Collection hierarchy, seem to me to be "toy" problems.  I would be 
> interested to read about non-trivial cases where Traits would solve a 
> significant real world problem.
Try to add 10000 Behaviors (or some other object that does not override 
Object>>hash) into a Set. Try to do the same to an IdentitySet. This bug 
is know from 2005. One reason it is not solved, is because of the 
separate implementations. The code duplication in the collections 
hierarchy affects more than you know, every day. Yes, by hurting their 
performance, among things.

> It has been my experience that 
> once something is implemented and working, unless there is a compelling 
> reason to justify it, the code is never revisited.  
Mine is very different. Andrew and I have spent a few days work recently 
removing a class that was not necessary from Traits, just to simplify 
the implementation.

> Management is 
> generally focused on allocating resources to things that will yield either 
> an opportunity for increased revenues, or reduced costs, and code 
> "cleaning" is rarely viewed as either.  
Then management is not up to speed on their software management 
techniques. Conceptual coherency, as a tool for controlling software 
development costs, is known at least for 25 years (see Mythical Man 
Month). I've read that introducing them to the concept of "Design debt" 
helps them understand the situation in their own terms.

> If it ever gets done (code 
> cleaning), it is usually silently piggybacked on required bug fixes by 
> individual developers who feel it is important.  Am I in the minority 
> here, or is this how commercial software development works in general?
I think your case is quite common, but certainly not the only case. But 
even in this case, reducing the cost of refactoring allows the Code 
Cleaning Special Forces to be more effective when they do on a mission.

> So I guess I don't see what Traits gets us that we can't already do in 
> Squeak with some judicious use of proxies, DNU and separate "behavior 
> only" and "state only" classes using accessors for all instance variable 
> access.  Is the real benefit in having tools that formalize this and make 
> it easy?
Getting the same benefits with less run time and design complexity 
sounds good to me... having the tools support the language features is a 
very nice bonus.

Daniel