Hi dean

do you ***really*** think that the Collection hierarchy is a toy  
example....
I'm not sure that we are talking about the same.

On 30 août 05, at 02:28, Dean_Swan at Mitel.COM wrote:

>
> 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?


Cleaning your design does not solve the problem that traits solve.
Read the papers. Sometimes we are forced to duplicate code or to  
write a lot of delegate methods just because we cannot simply reuse
method dictionary. This is what traits are about.

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