On 31 May 2013 12:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 31, 2013, at 1:28 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 31 May 2013 12:01, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi Frank,
On Wed, May 29, 2013 at 11:45 PM, Frank Shearar <frank.shearar@gmail.com> 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