Some questions about new traits (Crismas edition) ;)

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

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

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

> 2009/12/28 Andreas Raab <[hidden email]>:
>> 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?

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

> Igor Stasenko wrote:
>>
>> 2009/12/28 Andreas Raab <[hidden email]>:
>>>
>>> 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.
>

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

> Igor Stasenko wrote:
>>
>> :) 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 problem with the behavior protocol is that has become bloated:
>
> {Behavior. ClassDescription. Class. Metaclass}
>        collect:[:each| each -> each selectors size].
>
> Version      Behavior   ClassDescription    Class Metaclass Total
> 2.3             116             86             45     29     276
> 3.6             165            122             68     42     397
> 3.10            241            138             89     50     518
>
> Note that although we've doubled the number of methods since 2.3 you only
> get north of 1000 methods when you add traits to it. Individually, at a 150
> methods or so, Behavior and ClassDescription are quite manageable. Wait
> until I'm through with a round of cleanup and I think I can give the 3.6
> version a run for its money - I'm optimistic that something around 50-100
> methods should be removable after installing NanoTraits.
>

>> 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 understand what you're trying to achieve here but one must be wondering
> why you think this would work any better with traits than with categories
> (which we have and use for this purpose).
>

>> 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.
>
> Certainly correct, and having a solution for that problem would be helpful.
> But I'm not sure how what you're proposing would help with that - you'd
> still have all the methods in class Object.
>

>> 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.
>
> But what does that defining that interface help with? And what effect has
> the multiplication of entities on other parts of the system?
>
> The way it's been used so far results in situations like seeing *seven*
> implementors of addSelectorSilently:withMethod: when there are only two, it
> results in having *three* additional variants of

>> 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.
>
> I can see how that would work better than in a system like Squeak, mostly
> because you're never going to look at the prototype's class, so you're never
> going to have to deal with its full complexity. However, I can't help but
> wonder how this works if traits require state, or if traits have conflicts.
>