----------- Reposting from squeak-dev (about nanotraits): ClassDescription , Metaclass ivars: traitComposition localSelectors has no uses.
Andreas using a TraitMethodProperties to hold a reference to original method, and then to trait. So, its easy to tell whether method is local or not, by asking it, without need of keeping a separate state. I find such approach less error prone, since method is the unit of manipulation for traits and asking it directly, where it came, seems more straightforward. It is, however incurs a little overhead: any method which comes from trait should keep additional state in MethodProperties (in fact , a subclass of it), while normally, most of methods don't need to have it. And sure thing, copying method over multiple method dicts, does not require you to care about keeping something else in sync (except categorizer, maybe). ---------- Stephane, i appreciate your way of doing things. Really, if something is 'not invented here' , its a signal to learn from it, how you could improve things, but not a signal to start bashing each other over and over again. For professionals, at first place should be the code, the idea and quality of implementation, but not where it came from. 2009/12/30 Stéphane Ducasse <[email protected]>: > Adrian > > What I would like to understand > - what part of the require algorithm could we unload? > because I imagine that the requirement analysis is > for the self sends deep up the hierarchy that may invoke an explicit > requirement > deep down the composition and this is not related > to the simple self explicitRequirement. I would be good to do a pass > because it would > clarify the code. I could give a try but I would prefer you to do it > and also we should not > rush this is not because squeak is getting frantic that we should - I > said that mainly for me. ;) > > - what is the impact from the tool perspective to have trait subclass > of class description > I imagine that you get less bug due to Trait dnu superclass and friend. > > I do not care about the install method I imagine that it is long and you can > throw it away. > > Now let us be smarter than some people think we are :) > What can we learn from nanotrait: > - is the composition more robust (I think that andreas change a bit > the operator) > - is the code simpler? > for example > push traitComposition into TraitOrganizer so that we > don't need to > duplicate it in three places (Class, Metaclass, > TraitDescription). > of course using trait you do not duplicate > - we have the opportunity to compare and weight pro and cons. > We could even write a workshop paper on it for fun (ok not that fun > :)). > Stef > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
