stephane ducasse wrote:
> Adrian master is what you are looking for.
>     http://www.iam.unibe.ch/~scg/Archive/Diploma/Lien04a.pdf
> and I'm sure that adrian can reply to you .

Thanks, this is exactly what I'm looking for.

Cheers,
   - Andreas

> 
> So thanks for asking and I will try to reply but I will travelling again.
> 
> Stef
> 
> On 28 nov. 07, at 07:17, Andreas Raab wrote:
> 
>> Hi -
>>
>> [Repost from a while ago. I'm still interested in finding out more 
>> about these issues - who maintains traits these days?]
>>
>> I noticed some traits inconsistencies in the latest 3.10 beta. If
>> someone could shed a light on those, I'd appreciate it:
>>
>> * Class definitions with traits:
>>
>> Class>>subclass: t uses: aTraitCompositionOrArray instanceVariableNames:
>> f classVariableNames: d poolDictionaries: s category: cat
>>
>> says this:
>>
>>   copyOfOldClass := self copy.
>>   newClass := self subclass: t instanceVariableNames: f
>> classVariableNames: d poolDictionaries: s category: cat.
>>   "..."
>>   SystemChangeNotifier uniqueInstance
>>     classDefinitionChangedFrom: copyOfOldClass to: newClass.
>>
>> This seems wrong because unless I'm missing something the
>> "copyOfOldClass" is the superclass of the class being changed and not
>> its old representation. This pattern seems to appear in all traits
>> subclass creation methods.
>>
>> * Class traits:
>>
>> fooTrait := Trait named: #TFooTrait uses:{} category: 'Tests'.
>> barTrait := Trait named: #TBarTrait uses:{} category: 'Tests'.
>>
>> classA := Object subclass: #TestClassA
>>   uses: fooTrait
>>   instanceVariableNames: ''
>>   classVariableNames: ''
>>   poolDictionaries: ''
>>   category: 'Tests'.
>> classA classTrait uses: fooTrait class + barTrait. "works"
>>
>> classB := Object subclass: #TestClassB
>>   uses: fooTrait + barTrait
>>   instanceVariableNames: ''
>>   classVariableNames: ''
>>   poolDictionaries: ''
>>   category: 'Tests'.
>> classA classTrait uses: fooTrait class + barTrait. "fails"
>>
>> Why is this? In particular considering that we can transform classA into
>> the desired shape via:
>>
>> classA := Object subclass: #TestClassA
>>   uses: fooTrait
>>   instanceVariableNames: ''
>>   classVariableNames: ''
>>   poolDictionaries: ''
>>   category: 'Tests'.
>> classA classTrait uses: fooTrait class + barTrait. "works"
>> classA := Object subclass: #TestClassA
>>   uses: fooTrait + barTrait
>>   instanceVariableNames: ''
>>   classVariableNames: ''
>>   poolDictionaries: ''
>>   category: 'Tests'.
>>
>> (note that in the above the obvious desire is to include the methods of
>> TFooTrait for both class and metaclass operations). Given that the
>> former doesn't work, I think this last example constitutes a bug. But
>> more importantly: What the rationale for disallowing the inclusion of
>> the same trait on both instance and class side?
> 
> normally this should not be a problem to use a traits from class and 
> instance side.
> At least this was never a limit of the model.
> 
>> * Fileouts:
>>
>> I was trying to file out a bunch of code with traits and found that I
>> can't file it in again. I've tried with other code and, for example,
>> Nile can't be filed out and back in either (if you need something to try
>> it with).
> 
> needs to be fixed :(
> The code of fileout is so bad I always wanted to rewrite everything.
> 
>> Monticello seems to work but at times this is a bit of a
>> heavy-weight solution. Any ideas?
>>
>> Oh, and lastly: Is there any documentation at all about the the
>> implementation of the traits kernel? (not the general approach; I'm
>> pretty clear on that but rather on the implementation itself) I seem to
>> remember having seen references to a thesis maybe but I can't remember.
>> Any pointers welcome.
>>
>> Cheers,
>>   - Andreas
>>
>>
>>
> 
> 
>