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 
addSelectorSilently:withMethod: (methodDictAddSelectorSilently:, 
basicAddSelectorSilently:, pureAddSelectorSilently:) when there is no 
need for any and more. This is classic MI madness.

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

Cheers,
   - Andreas