Hi Göran,

> - Can I use the standard libraries and not know about Traits? 
> Before you say "yes" :) think it through, for example, if I 
> edit a method in a class that comes from a Trait (I haven't 
> read all your papers yet, but I did try to print some of it) 
> what happens? 

Absolutely! The idea is that in the regular browser, changing a method
in a class that comes from a trait will define a new method that is
local to the class and --- according to the semantics of traits ---
overrides the method coming from the trait. This means that such an edit
has the exact same consequences (i.e., it only affects the class and its
subclasses) as if the class were built without any traits at all. 

Similarly, if you remove a method in a class that comes form a trait,
the method gets "excluded from the composition" (i.e., it is not removed
from the trait but only excluded from this particular application of the
trait), which means that it has the expected effect for the programmer
who does not know (and does not want to know) that the class is in fact
built from traits.

> Am I editing the Trait? And then I am affecting 
> other classes using it? So I am guessing (just
> guessing) that people *do* need to know about Traits (if we 
> use them for standard libraries) or else they will get 
> confused. Correct?

No. As I said above, the standard browser hides traits in a completely
consistent way. As a consequence, a programmer that does not want to
know about traits can use the standad browser, which lets him *view and
edit* any code (even if it is built from dozens of nested traits) in the
traditional way without ever accidentally affecting any other classes.
This is possible thanks to the beauty of the traits model, which
features the flattening property (i.e., methods in traits have no
special semantics) and allows the composite entity (in this case the
class) to make any kind of local changes (such as modifying or removing
methods obtained from a trait) without affecting the traits itself. This
is also the reason why traits do not suffer from the fragility problems
known from mixins and MI.

> - If I don't use Traits and don't use any libraries using 
> Traits (given that no standard libraries use them) and if 
> I... use ordinary browsers etc. What is the effect on me? 
> Does Traits have any effect then at all? Just asking to get a 
> feel for this.

If you are using no libraries that use traits, then traits have
absolutely no effect on you, except that there are a handful of
additional classes in the kernel (such as Trait, TraitDescription,
ClassTrait, etc.) that most people are not interested in anyway.

However, things are even better because, as I explained above, one major
advantage of traits is that they have virtually no effect on people who
do not want to know about them even if they use libraries built with
traits! 
The only thing to make this work in practice is to tweak some of the
existing tools a bit. We have already done this for the traditional
System Browser, which displays the code always as if no traits were used
and makes sure that also edits behave exactly as if no traits were used
(i.e., changes only affect a class and its subclasses but *not* other
classes using the same traits).

> - Does the old tools work if we introduce Traits or do they all break?
> :) 

Because all the work is done at composition time (i.e., the method
dictionaries of all classes look exactly as if no traits were used) Most
of the old tools (such as "implementors of..." and "senders of..." etc.)
work just fine. However, we found that for some of them require minor
tweaks to get the perfect illusion of a trait-lest image.

What is more work is to design the new tools (such as the trait browser)
for the programmers who actually want to know about traits and use them.
This is because these tools need to show how classes are built from
traits and give the programmer the choice of overriding/removing a trait
method in a certain class or actually changing the trait where the
method is actually defined. Also, we need to make sure that for those
programmers, tools like "implementors of..." and "senders of..." take
methods defined in traits into account.

> Yes, perfect. So can we then decide on that - first a beta 
> (or alpha or whatever you like to put in our hands) - then we 
> take first look, and then probably solicit some feedback from 
> stakeholders.

Sounds good to me.

Cheers,
Nathanael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of goran.krampe at bluefish.se
> Sent: Donnerstag, 24. Februar 2005 15:43
> To: The general-purpose Squeak developers list
> Subject: RE: To Traits Or Not To Traits (Was: Re: Stefs 
> roadmap for 3.9,time to get it nailed down)
> 
> 
> Hi Nathanael!
> 
> =?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
> > Hi guys,
> > 
> > > Nathanael and adrian will certainly reply in length here. 
> What I can 
> > > tell you is that it is possible to have traits as package 
> but this 
> > > is a sweet dream because each time the kernel will 
> changes then you 
> > > will have to fix traits.
> > 
> > I agree with Stef. While it would be possible to have Traits as a 
> > package, I don't think that this is a good idea for several 
> reasons. 
> > First, it would mean a lot of care and work to make sure 
> that provide 
> > a package that is compatible with newer Squeak releases. More 
> > importantly, I think that it kind of defeats the prupose of a 
> > langauage extension like traits if it is optional because 
> this means 
> > that one cannot take advantage of it in any of the 
> non-optional code.
> 
> This is what I thought - I just want to hear it spelled out. :)
>  
> > However, the good news is that even if traits are part of the basic 
> > image, people do not have to use and deal with them if they do not 
> > want to. So, there really should be no disadvantage/change 
> for people 
> > who just want to ignore them. But as I said in my last 
> email, I agree 
> > that
> 
> I would like to hear more about that. Let me take the role of 
> a Traits-hater here:
> 
> - Can I use the standard libraries and not know about Traits? 
> Before you say "yes" :) think it through, for example, if I 
> edit a method in a class that comes from a Trait (I haven't 
> read all your papers yet, but I did try to print some of it) 
> what happens? Am I editing the Trait? And then I am affecting 
> other classes using it? So I am guessing (just
> guessing) that people *do* need to know about Traits (if we 
> use them for standard libraries) or else they will get 
> confused. Correct?
> 
> - If I don't use Traits and don't use any libraries using 
> Traits (given that no standard libraries use them) and if 
> I... use ordinary browsers etc. What is the effect on me? 
> Does Traits have any effect then at all? Just asking to get a 
> feel for this.
> 
> - Does the old tools work if we introduce Traits or do they all break?
> :) 
> 
> > we should go step by step, and the next step is a beta that allows 
> > people to see what it would mean to have traits in the 
> image. I'm sure 
> > that this will make things a lot less scary...
> 
> Yes, perfect. So can we then decide on that - first a beta 
> (or alpha or whatever you like to put in our hands) - then we 
> take first look, and then probably solicit some feedback from 
> stakeholders.
> 
> As a first rough plan. Ok?
>  
> > Cheers,
> > Nathanael
> 
> Cheers, Göran
> 
>