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
