While I find all this discussion fascinating, I would like to share a few 
thoughts on the idea of including Traits in mainstream Squeak.

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.

My second concern is regarding how Traits should/could/would be used.  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.

It would seem to me that the kind of reuse that Traits enables is the kind 
that isn't apparent at design time, since individual classes of object are 
usually designed separately and often by completely different people.  The 
common behavior and opportunity for code reuse might only become apparent 
after the initial design is implemented.  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.  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.  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 would even suggest that single inheritance doesn't get used that much in 
practice.  I see an awful lot of C++ where classes are root classes and 
implement a singleton object.  I see poly-morphism used a lot, but not 
much inheritance.  I also see STL used a lot to get common syntax 
container objects, that you get with the standard Smalltalk Collection 
hierarchy anyway.

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?

Is Traits implemented by just pointing a class's method dictionary entries 
to the approprate seemingly class-less compiled method defined in a Trait?

I guess I don't fundamentally oppose including Traits in mainstream 
Squeak, as long as it's still possible to ignore it and it doesn't cause a 
decrease in performance for commonly used objects (i.e. the Collection 
hierarchy).  From what I've read in the whitepapers, it seems it should be 
safe and easy to ignore, so the only question I guess would be 
performance.

And lastly I will just say that as others (Andreas) have pointed out, 
maximising code reuse is not always desirable.  I can see the argument in 
favor of code re-use to propagate common behavior without having to find 
every duplicated variation, but there is also the other side of the 
argument where a single bug in a common, highly reused method can cause a 
lot of things to break that might otherwise work properly.

                -Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050829/1acf27f6/attachment.htm