Philippe Marschall wrote:
>>  It is perhaps possible to go one step further (or go back, for that matter)
>> and have no instance traits and no class traits, but just traits (subclass
>> of ClassDescription, instVar 'users'). It can be applied to either side of
>> some class, since the whole machinery has no requirement other than
>> #traitComposition (as far as I've seen). Wouldn't that make the exercise
>> less complex and more clear, or am I missing something.
> 
> It would also be interesting to see if getting rid of sharing
> CompiledMethods would simplify the implementation.

Actually, very little. The only piece that distinguishes a version which 
shares from a version which doesn't is that the former has a conditional 
that says "only recompile when this method has a super-send". Outside of 
that there really is no difference.

 From what I can tell, most of the complexity of the implementation of 
traits originates from having to broadcast and handle changes to methods 
in traits to their users (managing local overrides etc) and to deal with 
the transformations along the way.

Cheers,
   - Andreas

> 
> Cheers
> Philippe
> 
>>  There may even be quite different compositions required for both sides of a
>> class. As an example consider making Traits (incl. their tests ;) for the
>> 5.3 Fundamental Protocols of ANSI Smalltalk 1997. This looks to be
>> impossible with dualistic traits.
>>
>>  /Klaus
>>
>>
>>
>>> Cheers,
>>>   - Andreas
>>>
>>>
>>>>> The extension points to the existing kernel are
>>>>> few (and could be made fewer) and loading and unloading would be
>> trivial
>>>>> with just a tiny bit more work.
>>>>>
>>>>> In any case, this is not a complete implementation but rather an
>>>>> illustration that the current implementation isn't the only way traits
>>>>> can be implemented in Squeak and that an alternative can be small,
>>>>> loadable, and easy to understand.
>>>>>
>>>>> Cheers,
>>>>>   - Andreas
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 
>