2009/12/8 Igor Stasenko <siguctua at gmail.com>:
> 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.
>
>

fully agree, that's what I tried to express

Nicolas

>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>