Just to voice my opinion, I agree with Daniel on this.  I feel like I want somebody to convince me that Traits is something I need.

I don't really understand Traits too well at this point, but I agree with Daniel that it seems to be of greater value for refactoring existing code than it is for writing new code.  How is this different from AspectS and Perspectives, or mix-ins for that matter?  My cursory (and perhaps incorrect) understanding leads me to believe that Traits is just another "flavor" of the same kind of thing.

Have there been any costs/benefits analyses done of this kind of system?  While I understand that it allows for a higher degree of reusability, I'm not convinced (yet) that it's worth the complexity it can add to the inheritance graph or the greater potential to break more classes faster by changing a highly reused method at the Trait level.  I understand subclassing and overriding a method from a superclass.  Traits is more complex.

Along the same line of thought, I wonder just how much utility can really be had from Traits?  Would refactoring the Collection hierarchy, for example, with Traits reduce the number of methods? code space? increase performance?

I would hate to see Squeak/Smalltalk gain as much "flexibility" as something like C++.  Will Traits make it any easier to do ill-advised things (i.e. write bad code)?

Traits strikes me a little like the kind of thing an optimizing compiler might do "under-the-hood", but it's not clear that this fine grain control is a "Good Thing"tm at the source level.

I am not saying that Traits should never be a "CORE" package, but IMO it is  FAR to early for it to even be considered for that yet.  It would
be very good to see it used for some "real" code (as opposed to examples contrived to highlight the value of Traits) so we can get a feel for where the strengths and weaknesses are.

To me, Traits is a much more experimental technology than Anthony's VI4 work (full closures, context stack unwinding, etc.), so I'm a bit wary.

					-Dean


> -----Original Message-----
> From: Daniel Vainsencher [mailto:danielv at netvision.net.il]
> Sent: Friday, February 14, 2003 8:43 PM
> To: The general-purpose Squeak developers list
> Subject: RE: Two important issues...
> 
> 
> If we learned something from the 3.3aModules, it is that for something
> to be accepted, it better come in small, edible bites. People 
> should be
> able to play with it from the beginning. Keep it in mind when you plan
> your releases.
> 
> * Do take a little time to get feedback on the demo you posted. I've
> read the web page, including the screen shots. I think a good way to
> provoke more feedback would be to provide a real tutorial that doesn't
> just show features, but explains how to do something useful, for
> example, a walk through a small refactoring or two of a known existing
> class. After all, that's the most important potential most people have
> seen in Traits for - refactoring existing classes. Creating a new kind
> of Circle doesn't speak to me at least... but I'd love to get 
> a feel for
> how the streams refactoring is done, or something like it.
> * Start posting some of the infrastucture in usable ways. The analysis
> code - package it up and put it on SM, even if the updating 
> is sometimes
> slow (or even without caching), so people can see it and 
> offer comments
> (maybe the analysis part doesn't require recompiling 
> ClassDescription?).
> If you require patches to the base system, start posting them 
> as [FIX]es
> and such, so when you have a product, it doesn't depend on too many
> changes itself.
> * Plan how the initial adopters will use the tool on their 
> own packages.
> Solving the big problems in the base image (collections, streams) is
> tempting, but it's not incremental. Start from the outside in - after
> Avi converts Seaside to use Traits (for example), the 
> decision to adopt
> will seem very different.
> * Articulate your architecture. Besides the theoretical 
> aspect, to adopt
> your code, people need to find their way around it. So even before you
> start coding, write up the components the system will 
> require. Write up
> your release plan, and request feedback on it. You don't have to
> implement every suggestion (you'd never finish), but you'll see how
> people think about things, and what needs more explaining, and what
> people need for a release to be useful.
> * I'll put this on the table - for something as deep as 
> Traits to become
> part of the image, you need to treat the adopting very 
> seriously. Think
> what happens if it get's accepted, then you decide to work on a
> different model, and then problems come up... we're stuck. Only way to
> avoid this is if other people seriously understand what it 
> does, and we
> take the adoption slowly.
> 
> I hope this helps. Let me know if I can help more.
> 
> Daniel Vainsencher