Fwd: [squeak-dev] Re: On traits composition

> 2009/12/8 Andreas Raab <[hidden email]>:
>> 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).
>