Re: Some questions about new traits (Crismas edition) ; )
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
>>> 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.
More information about the Squeak-dev