Hi Andreas
I haven't got round to looking into this so far...
On Nov 28, 2007, 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.
yes, this seems wrong. Not sure why the notification should be required here at all, since it should be triggered in ClassBuilder>>name:inEnvironment:...
- 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"
I guess you mean: classA class uses: fooTrait classTrait + barTrait instanceVariableNames: ''
classB := Object subclass: #TestClassB uses: fooTrait + barTrait instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Tests'. classA classTrait uses: fooTrait class + barTrait. "fails"
and here instead: classB class uses: fooTrait classTrait + barTrait instanceVariableNames: ''
The problem with is that you have the barTrait on the instance side and now you try to remove its associated trait on the class side (barTrait classTrait). This should be avoided since traits come always in pairs of instance and class side. If you add a trait on the instance side, its classTrait gets automatically added to the class side of this class or trait. An exception are traits that you only want to add to the class side. They cannot have methods on their class side.
What you want to do is probably:
classB class uses: fooTrait classTrait + barTrait classTrait + barTrait instanceVariableNames: ''
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'.
yes, but there is a difference (see explanation above):
classA class traitComposition --> TFooTrait classTrait + TBarTrait + TBarTrait classTrait
(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?
- 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). Monticello seems to work but at times this is a bit of a heavy-weight solution. Any ideas?
I agree, fileouts are sometimes handy. I implemented this but only used it sparingly. There is also a test, which is green. So apparently this is a bug.
Adrian
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