[squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

Andreas Raab andreas.raab at gmx.de
Mon Dec 28 13:00:46 UTC 2009


Igor Stasenko wrote:
> 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?

A good chunk of the difference is simply counting, so takes these 
numbers with a grain of salt. In terms of features I did one 
simplification namely leave out all the Traits-Requires stuff since it 
was neither used nor needed for making NanoTraits functioning. It'd be 
trivial to put it back as an add-on, though I don't see what it'd be 
good for (it looks like some research tool). Other than that there 
should be no observable difference.

The main reason why NanoTraits are smaller is *precisely* because it 
doesn't use traits to implement traits. It's a great example for how MI 
makes systems necessarily and needlessly more complex and creates more 
problems than it solves. The tools shape the design and if you're going 
to design for MI you *will* make things more complex than you'd 
otherwise have. I've done it myself in the past when I was still 
believing that MI could solve any problem. Turns out it doesn't. It 
creates problems.

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

How does #isTrait suit you? ;-) It's actually the main differentiator 
and I changed various places from using #isKindOf: Trait to using 
#isTrait to provide proper compatibility. See recent checkins.

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

Hell, yeah! I want an unloadable traits implementation so that when 
people finally realize that MI isn't going to solve their problems we 
can just drop it.

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

Over my dead body. I am just going to great length to clean up after the 
insane amount of complexity in a core part of the system caused directly 
by the use of MI. And you are asking for *more* traits? Could someone 
please come up with ONE example where MI (traits in particular) solve an 
*actual* problem and not just some academic BS?

I don't mind having traits for users to experiment with - and 
unfortunately we have committed to supporting traits in the past and 
because of this I'll accept that we'll have to support them in the 
future. But I will fight the use of MI in core system areas unless there 
are very clear and obvious benefits.

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

You get decomposition by delegation, not multiple inheritance. 
Decomposition means breaking things into self-contained *objects* with 
well-defined responsibilities, not traits.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list