On 31 May 2013 12:32, Stéphane Ducasse <[email protected]> wrote:
>
> On May 31, 2013, at 1:28 PM, Frank Shearar <[email protected]> wrote:
>
>> On 31 May 2013 12:01, Damien Cassou <[email protected]> wrote:
>>> Hi Frank,
>>>
>>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar <[email protected]>
>>> wrote:
>>>> I have a Trait TGroup that requires #*, #identity and #inverse. I want
>>>> to construct a TField by composing TGroup with itself. One TGroup will
>>>> form the operations #*, #one, and #reciprocal while the other will
>>>> form #+, #zero and #negated.
>>>>
>>>> I don't want #identity or #inverse, because these apply to one
>>>> operation, and it makes TField's API ambiguous. That's what
>>>> TraitExclusion is for.
>>>
>>> maybe a diagram would help
>>
>> In explaining the problem, or an an alternative to the crazy
>> composition? I rather think that this - which doesn't work, and
>> prompted the question in the first place - is rather readable... _and
>> executable_:
>>
>> (TGroup @ {#* -> #+. #inverse -> #negated. #identity -> #zero} +
>> TGroup @ {#inverse -> #reciprocal. #identity -> #zero}) - {#identity.
>> #inverse}
>>
>> What I don't understand is
>> (a) why exclusion only applies to the rightmost trait in the composition and
>> (b) why aliases either break (in Pharo [1])
>
> do they?
I'm not sure what "they" refers to. Assuming you meant "do aliases
break in Pharo?" yes they do: the alias expects the new name to
already exist in the method dictionary. So if you write your trait
Trait named: #TMyTrait
uses: TSomething @ {#aMethod -> #notWrittenYet}
category: 'Thing'
then you get a KeyNotFound because TMyTrait doesn't have
#notWrittenYet in its method dictionary. It should be fairly easy to
fix; I just raised the ticket.
If you meant "do exclusions only apply to the rightmost trait?", yes
they do. The comment in both Pharo and Squeak say that - binds tighter
than @ or +. That's fine. To me, that would mean that S + T @ {#m ->
#z} - {#m} would remove #m from T. But I thought that (S + T @ {#m -
#z}) - {#m} would mean "remove m from S + T @ {#m - #z}", but it
doesn't. That might simply be a TraitComposition bug. I don't know,
which is why I'm asking :)
>> or do nothing (in Squeak),
>> where I'd expected to see implementations saying "self requirement".
>
> we removed self requirement because it was slow to compute in interactive
> mode.
Ah, ok. Fair enough!
frank
>> frank
>>
>> [1] https://pharo.fogbugz.com/default.asp?10803#78542