[squeak-dev] Re: On traits composition

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Dec 8 09:57:42 UTC 2009


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

Nicolas



More information about the Squeak-dev mailing list