---------- Forwarded message ---------- From: Igor Stasenko <siguctua@gmail.com> Date: 2009/12/8 Subject: Re: [squeak-dev] Re: On traits composition To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org> 2009/12/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

2009/12/8 Andreas Raab <andreas.raab@gmx.de>:

...

Igor Stasenko wrote:

...

T1+T2 should mean 'apply T1 then T2', but not 'apply combination of T1 and T2'. Its much easier to implement as well as easy to understand & follow.

That's what I'm thinking as well.

...

Also, in Pharo list i suggested extension to exclusion operator:

in addition to: T1 - selectorsArray "{ #sel1. #sel2 }"

also have:

T1 - T2

which should transparently behave as:

T1 - (T2 selectors)

and mean: apply all from T1 , except selectors in T2.

I'll leave this as an exercise for the interested reader :)

...

Btw, i am curious about one thing: Since traits allowed to hold method for both instance side and class side.

Ah, yes. Classes and metaclasses and traits. Last time we had this discussion it was pretty clear that this whole area is not well-understood. That you can only apply a trait without class-side methods to a class for example, causes all sorts of irritation when you later add a class method to the trait, thereby making it non-applicable to compositions where it's already used. It's inconsistent at least (broken as far as I'm concerned since you can create compositions that can't be recreated).

...

Now, how i can specify a composition, which applies my trait, except #isel1 and #csel2 ? So, final class should have #isel2 method at instance side and #csel2 at class side, but not #isel1 and not #csel2. And what is a correct syntax for defining such composition in class definition?

Yes, that's just more inconsistencies resulting from the same basic problem.

Cheers,  - Andreas

Since classInstVarNames are defined in a separate declaration, I do not see why it couldn't be so for Traits. This would lead to some simplications. A possible POV is to handle #class as an ordinary message. It could eventually return any object (squeak specific implementation apart). So why put requirements on the protocol of object answered by #class and not on the protocol answered by #asInteger ? It is well known the second is a Boolean after all... If we don't put protocol requirements on self class, we then do not need any class side Trait, do we ? (I mean they could just be ordinary Traits).

IMO ideally, trait should NOT care where it applied to (be it class, metaclass or any other object). It should expect that object supporting a certain Behavior-based protocol (like #setTraitComposition:) but nothing more than that. Naturally, trait could be seen as a partial behavior, and so, it should  be applicable to just behavior only, not to two behaviors at once (class/metaclass). I think this i a clear case, where we could have a much less complex implementation by sacrificing the 'class side' view of trait (ClassTrait). Because, one could always create a two separate traits (TApple , TAppleClassSide) and apply each one independently: Apple uses: TApple.. Apple class uses: TAppleClassSide. -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.