Excellent
So we should finish 1.0 so that you get some cycles for 1.1 :)
>> What I would like to understand
>> - what part of the require algorithm could we unload?
>
> Everything can be unloaded.
Good I tried 5 min in a wild way but I failed but ok it was quite wild
:)
>
>> 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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
