[squeak-dev] Re: On traits composition

Igor Stasenko siguctua at gmail.com
Tue Dec 8 10:48:24 UTC 2009

2009/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2009/12/8 Andreas Raab <andreas.raab at 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

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.

More information about the Squeak-dev mailing list