Hi Daniel -

Daniel Vainsencher wrote:
> Yes, at the moment, we're using Traits lazily to avoid duplication and 
> inappropriate inheritance. We are not actively refactoring other parts 
> of the system at the moment. Doing so would probably make the merge into 
> mainstream Squeak more difficult.

Out of curiosity: I studied the use of traits in the kernel classes and 
it wasn't clear to me how you decide on the granularity of the traits 
involved. Can you say more about this?

For example, I think ClassDescription uses roughly 15 traits, many of 
which seem only to be used by ClassDescription/TraitDescription so there 
seems comparadly little reason to (for example) define 
TCopyingDescription, TCompilingDescription, TPrintingDescription etc. 
separately. Looking over the methods involved it almost feels as if the 
decision for defining the traits has been done along the lines of 
protocols / categories. Is this correct? In which places have you been 
avoiding inappropriate inheritance?

It seems to me that a valid alternative for avoiding inheritance 
problems is instead of duplicating the Behavior/ClassDescription/Class 
hierarchy via TraitBehavior/TraitDescription/ClassTrait would be to make 
  Trait delegate to an appropriate class description (e.g., a trait uses 
a class description for managing the Behavior side of things). Can you 
say anything about how such a design would have affected the definition 
of traits for these kernel classes themself?

BTW, the reason I'm asking these questions is to get a better 
understanding on how one uses traits effectively. Looking over the 
current uses it struck me that using a large number of fine-grained 
taits can make it actually harder to understand the system. At least 
that was my feeling when I looked over the current structure - none of 
the traits are fully defined internally and it's really hard to go 
fishing for what you still need to implement to "make it work" (I 
actually really miss state here - I think it would be much easier if you 
could see that someone wrote this with having in mind that "X would be 
an instance variable"). I tried playing with the required browser but it 
felt non-conclusive to use (it felt like there were random methods shown 
in the required category).

Also, since you are asking for "near term feedback" I think it is 
critical that one be able to see which methods come from traits and 
which one's don't. For example, I was curious if Class had any of its 
own methods or if all of the methods come from the three traits it 
uses[*] and also which traits are used by which classes (e.g., "all 
users of TVariablesClass").

[*] Similar question here: What were the design criteria to make Class 
use three traits that (I think) are not used anywhere else? Which 
methods were left in class Class and why?

In general, I think it would be helpful if some guidelines could be 
established for how to use traits in practice. Just knowing how and why 
you decided to factor the kernel classes the way you did would be a good 
start. Oh, and comments for the traits might be helpful too ;-)

Cheers,
   - Andreas