----------- 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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.