2009/12/28 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> 1. diff the number of lines between existing traits implementation & yours
>> ?
>
> It's a bit tricky to get a precise comparison, since Berne traits reuse
> various methods across Kernel-Classes and Traits. OTOH, there are many
> methods that will be removed from Kernel due to completely unnecessary
> complexities. I think the real comparison can only be done if you look at
> the totals of Kernel+[Nano]Traits before and after and since I haven't done
> the cleanup yet there is a bit of a problem in comparing this precisely. But
> you give an idea, here is a bit of data measured as follows:
>
> #('Traits' 'Traits-Kernel' 'Traits-Kernel-Traits' 'Traits-Composition'
> 'NanoTraits-Kernel' 'NanoTraits-Tests') do:[:pkgName| | pkg |
>        pkg := PackageInfo named: pkgName.
>        Transcript cr; show: pkg name;
>                tab; show: pkg classes size;
>                tab; show: pkg methods size.
> ].
>
> 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?

> 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.
>
>> 2. tools support, MC, Browser etc ?
>
> Same as before. Slightly better on older systems (i.e., 3.8 based) because
> browsers can cope with traits as is and mostly don't need special support
> (i.e., using #classSide etc).
>
>> 3. are there some common protocols with old traits, so one could use
>> traits for metaprogramming?
>
> As far as black-box reuse is concerned, there is no difference at all. There
> is also plenty of common stuff for the internals but it's very hard to know
> which protocols a particular client would use.
>
Well, browser should use some protocol to distingush between traits & classes,
trait methods and regular ones etc.. As well as MC, SystemNotifier ,
changesets etc.

Do you plan to fully adopt new traits in trunk (means completely
replacing current ones, of course)?

>> I haven't time to take a look at your code. But if it is smaller &
>> less complex than current version, i will vote for it.
>
> Try it. Load it via:
>
> (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.
>
AFAIK, Pharo cleaned-up some stuff , removed this particular trait.
I am however, think that putting traits in use for core classes having
one VERY IMPORTANT aspect,
that in this way we can decompose a bloated protocol(s) into a number
a smaller ones, with well-distinguished roles,
aside of code reuse.

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

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.

>
> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.