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



More information about the Squeak-dev mailing list