Hi

On Saturday, February 15, 2003, at 04:44 AM, Swan, Dean wrote:

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

But why don't you try the image nathanael provided and read the papers 
just the examples.

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

Traits does not have to do anything with aspectS. This is mixin like 
model but much more
simpler and scalable. Read the paper this is explained.


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

No traits is simpler. We refactored the collection hierarchy and we 
gain in code reuse
and in having a conceptually cleaner hierarchy, where we do not need 
all these Should not implement.



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

Read the paper

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

But people can use or not traits. And Traits are just groups of methods 
that can be combined together.


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

But at the source level this is ***Exactly the same and normal 
smalltalk code***
there is no magic.

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

This is what we will test, but if the squeak people wait too much or 
are not responsive enough
they may end up not getting it and this will not be our fault.

> 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
>
>
Prof. Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes