On Dec 30, 2009, at 09:53 , Stéphane Ducasse wrote:

> Adrian
>
> What I would like to understand
>       - what part of the require algorithm could we unload?

Everything can be unloaded.

>       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. ;)

Yes, I can take a look. But as you say, not right now ;)

>       - 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'd also like to look closer into NanoTraits. But so far I failed to  
get a trunk image with it. I downloaded Squeak3.11-8472-alpha.image  
from the ftp server and did an update to 8660 but I still get the  
outdated traits implementation of Squeak.

Inheriting from ClassDescription you need less code but you inherit  
too much so I wonder how you deal with the inherited behavior that  
does not make sense for traits.

> I do not care about the install method I imagine that it is long and  
> you can throw it away.

Me neither. This was a joke ;)

Adrian

> 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


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to