>>
>>
>> Package Classes Methods
>> Traits 59 873
>> Traits-Kernel 22 343
>> Traits-Kernel-Traits 17 215
>> Traits-Composition 7 127
>> NanoTraits-Kernel 9 190
>> NanoTraits-Tests 9 122
>>
>
> oh, that's quite a big difference.
> I am curious, is it because of simpler implementation or because of
> smaller feature set?
First two remarks
-we should remove the old infrasturcture for requirements computation
that has not
much with traits.
- second counting number of classes is not a good measure.
Do you think that this is better to have one Refactoring class or 18
Refactoring classes?
>> The "meat" for NanoTraits is 9 classes and 190 methods And, after installing
>> NanoTraits there will be many other methods removed in Behavior and friends
>> which are only the result of unnecessary complexity in Berned traits. It
>> will be *significantly* simpler by any measures and unloadable.
This is probably true.
This is why I want to see the result of nano traits.
>>>
>> (Installer repository: 'http://www.squeaksource.com/NanoTraits')
>> install: 'NanoTraits-Kernel';
>> install: 'NanoTraits-Tests'.
>>
>> then install it using:
>>
>> NanoTrait install.
>>
>> (WARNING: Be prepared to throw the image away if something goes wrong)
>>
>>> I just have some concerns about common protocols, so developers could
>>> use traits in both pharo & squeak without need of refactoring.
>>
>> Fair enough. I don't think there's much difficulty as far as extending the
>> existing protocols go. We could even add compatibility traits
>> (TCompilingBehavior etc) that model the old structure if people want to add
>> extension methods to those.
>>
>
> And hey, my code is always MIT, so if the Pharo folks are interested, tell
>> them they're more than welcome to use and enhance it. The squeaksource
>> repository is world-writable.
I'm really interested in a cleaner/smaller/less intrusive trait implementations.
Contrary to what some not so clever guys thought it was always the case. ;D
Just no time right now. shit..... back project wirting
> Aye, i CC this conversation to pharo list.
> Personally, amount of code is the major criteria for me to choose
> from. Especially for things in Kernel.
> And especially, if it doesn't having heavy tradeoffs.
Igor please rephrase your thoughts! :)
amount of complexity !!!
not amount of code!!!
Come on number of classes is not a decent measure in presence of late
binding!
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
