Hi Dean

As Stef already said, there is a lot of information in the paper that
has been accepted to ECOOP:

- What are traits
- How can traits be used (examples)
- Why are traits significantly simpler than multiple inheritance and
mixins
- Why traits lead to code that is _always_ easier (or at least as easy)
to understand than the same code without traits.
- How we used traits to refactor the ST collection hierarchy
- etc.

In addition, there is a paper that gives more details about the
refactorings. A preliminary version is publicly available and we are
just in the process to give some more details about the refactorings and
then submit it to OOPSLA.

> I would hate to see Squeak/Smalltalk gain as much 
> "flexibility" as something like C++.

Trust me, I would not at all like that, either. That's why our main
guidline during the development of traits was to have a model that is
simple, even if it does not allow fancy things that are hardly used or
could easily be abused.

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

I don't agree. Traits are also extremely well suited to write new code.
Once you have a library of traits, you can compose new classes by
reusing these traits rather than writing them for scratch. You just pick
what you want to use and glue it together.

And as I said, since traits always allow one to look at the code as if
no traits were used at all, the resulting code is always at least as
easy to understand as the corresponding code without traits. In fact, in
the flat view (which also allows editing the code), it is impossible to
say whether the code was implemented with traits or without.

Have a look at the paper for examples.

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

Well, at the moment, there are many classes that have tons of subclasses
(e.g., Object, Morph, etc.). If you introduce a buggy method there, you
may of course break the subclasses. This is the same with traits: If you
introduce a buggy method in an often used trait, you can of course break
a lot of classes. 

The only difference is hat traits allow better reuse. This means that
you have less duplication of code and therefore more reuse.

If I understood you right, your argument is: If a method is reused more
often, then chanhging this method may break more things. But then I ask
you why you don't put a copy of all the methods in Object into each of
its subclasses. Like that you can be sure that changing something in
Object never breaks a subclass. This means that if you would really mean
your argument, you would also argue against code reuse by subclssing.

It is a matter of its nature that, more code reuse always means that
changing a reused method can potentially break the things that reuse
them. But fortunately, you always have the option to not change the
general method and just implement a specialiced method at the place
where you really need it: If you have a method in Object and you want to
change it for all its subclasses, then you change it there. But if you
only want to change it for Point, then you can just override it there.
This is the exact same thing in traits!

(Please have a look at the paper to see why traits does not suffer from
the "fragile hierarchy problem" of mixins).

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

Well, we are not qite finished, but here are some rough numbers:

(1) number of methods: -12%
(2) code space: -13%
(3) number of methods that are implemented too high in the hierarchy:
-15%
(4) same performance (except usage of accessors instead of direct
instance variable access).

Comment to (3): In the current cllection hierarchy, there are way more
than 100 methods that are implemented "too high" in the hierarchy just
in order to allow code sharing. However, this means that there are
subclasses, where these methods simply return an error. Unfortunately,
this can not always be seen very easily. As an example, imagine that a
method "grow" is implemented too high and yields an error in a certain
subclass. Now there are typically many methods sthat indirectly call
"grow" and therefore break in the subclass. (Imagine a method "addAll:",
which calls "add:", which calls "grow"). For a user it is therefore
impossible to see which of the many hundrets methods are actually legal
for a certain collection class. (He would need to look at the code of
every single method and see whether it calls a method that breaks). For
certain classes (e.g., WriteStream), there are 40 and more methods that
just break because they _indirectly_ call a method that is illegal. This
makes it practically impossible to really understand the hierarchy!

With traits, _zero_ methods need to be implemented too high. Every class
just has the methods it also supports. 

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

Isn't the fact that code with traits is generally easier to understand
than code without traits a good argument?

Nathanael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Swan, Dean
> Sent: Samstag, 15. Februar 2003 04:44
> To: 'The general-purpose Squeak developers list'
> Subject: RE: Two important issues...
> 
> 
> 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
>