On Dec 30, 2009, at 10:44 AM, Igor Stasenko wrote:
----------- 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).
I have to digest that paragraph (a bit difficult).
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.
Thanks. I really believe what I wrote :) No marketing in it. I always want to learn from alternate design. I think that in general there is a chance people need another view to things to understand the world.
For professionals, at first place should be the code, the idea and quality of implementation, but not where it came from.
;)
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project