this is interesting. I had on my todo to look at the old implementation of andreas since years. Adrian it would be really interesting to check because having a smaller/with less impact traits implementation would be cool.
Stef
>
> My experiments with a simpler traits implementation are starting to bear
> results. Attached a version of NanoTraits which is the smallest
> implementation of traits that I could come up with. Making it loadable inside
> a current trunk image has been a bit of a challenge since it needs to operate
> side-by-side with the existing traits during load (apologies for the various
> isKindOf:'s), but it seems to work fairly well now (fingers crossed). There
> are few differences to the Berne trait implementation including:
>
> - TraitDescription is a subclass of ClassDescription. This is the main
> simplification since it avoids creating a dual trait/class hierarchy. It
> comes at the "cost" of having potentially support for instance variables in
> traits (i.e., stateful traits) but since this isn't exposed there is very
> little actual overhead.
>
> - NanoClassTrait is the class of NanoTrait (i.e., the same meta structure
> that classes have). Since this models exactly the structure that classes
> have, it makes browser integration significantly simpler (NanoTraits would
> work fine in 3.8 for example without changing browsers etc) and allows us to
> remove the (now unecessary) additional tool support.
>
> - Methods used from other traits retain a "method home" reference so that for
> any method in a class you can tell whether it was defined locally or in some
> other trait. This makes several things *a lot* easier and will allow us to
> get rid of all the localSelectors stuff in ClassDescription in the next pass
> (Igor - this gives you the information where a method is from without poking
> in other places; just ask i.e.,
> (ClassDescription>>#addSelectorSilently:withMethod:) methodHome ==>
> TAccessingMethodDictDescription)
>
> - Some previously invalid trait composition are now valid, in particular T -
> {#x} - {#y} (meaning T- {#x. #y}) as well as T @ {#x->#y} @ (#a -> #b}
> (meaning T @ { #x -> #y. #a -> #b}.
>
> - You can't mix Berne and Nano traits. If you try it, things will blow up
> (incompatible internals).
>
> - You can't mix Berne and Nano traits tests. I don't know why but if you run
> them at the same time things go wrong.
>
> To install NanoTraits:
> * Load NanoTraits-Kernel.st
> * Load NanoTraits-Tests.st
> * Load NanoTraits-Extensions.cs
> * Run the NanoTraits-Tests
> * (assuming all tests are green) execute: NanoTraits install.
>
> This will make NanoTraits the default traits implementation and convert any
> existing traits. I've successfully played with Nile (the only other traits
> stuff I was aware about besides the class kernel which is a bit difficult to
> experiment with) but from what I can tell everything should work just fine.
>
> The one extra thing I'm seriously considering after our recent discussions is
> to change NanoTraits to actually use mixins to implement traits composition.
> What this would mean is that instead of adding trait methods to a class
> directly, they would be added to a (hidden) superclass. Composition rules
> would be unaffected by this change but it would solve the issue of trait
> methods messing up the methods *actually* defined in a class, showing a seven
> times when looking for implementors and more.
>
> Consider this my holiday gift to the community :-)
>
> Cheers,
> - Andreas
>
NanoTraits-Kernel.st.gz
Description: GNU Zip compressed data
NanoTraits-Tests.st.gz
Description: GNU Zip compressed data
NanoTraits-Extensions.cs.gz
Description: GNU Zip compressed data
> >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
