2009/12/28 Andreas Raab <andreas.raab at gmx.de>:
> 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?
>

:) The Behavior protocol is insane by itself. I'm not sure that
removing composition from it, will make it less bloated or less
complex.
The nature of problem lies elsewhere (in same place where lies the
problem of bloat in Object  and Morph protocols)
- same object can play many independent roles depending on use scenario.

Grouping the methods per role is, what i think traits could help with.
If method #foo and #bar defined in same trait, then
they serve for a single role (unless trait developer is a dumbass ;).
And in case if i would want to change the role, or remove it, i will
know exactly, what methods i may need to touch & revise, instead of
staring at 1000 methods in a single class and wondering how they
depend from each other.
I sense it, as a method's category, living on its own, without binding
to concrete class, not as a way to introduce MI.

I look on it strictly from practical perspective, not academic or
experiment. People usually, can't keep too much things at once in some
context.. 10, 20 , 30 methods... Getting over that, you soon start
spending time revisiting same places again and again to 'refresh' your
mind-cache.

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

As i already said, i don't perceive Traits purely as a MI 'addon'.
Never seen much fun in use MI, since learning C++ std lib classes &
perusing its docs.
A most useful aspect of Traits, as to me, is being able to define a
clean, standalone interface (role), irrespectively to any
(single/multiple) inheritance models and
even to smalltalk class/behavior model.

I've implemented own version of prototypes, and use traits to fill
prototypes with methods. I found that they naturally complement each
other in squeak environment,
because i can use standard dev tools for designing my proto behaviors
using traits, which then i can use. I even want to add a dependency
support to it, so
if you changing the trait method, all prototypes with that trait will
be updated accordingly.


> Cheers,
>  - Andreas



-- 
Best regards,
Igor Stasenko AKA sig.