Dean_Swan@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