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 > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project NanoTraits-Kernel.st.gz (10K) Download Attachment NanoTraits-Tests.st.gz (11K) Download Attachment NanoTraits-Extensions.cs.gz (10K) Download Attachment |
Free forum by Nabble | Edit this page |