Hi

> (4) same performance (except usage of accessors instead of 
> direct instance variable access).

I would like to clarify that we have not done real benchmarking of the
refactored hierarchy yet. Therefore, I can only say that in principle,
traits do not introduce a performance penalty except for the indirect
instance variable access. 

Nathanael

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