On 4 June 2013 10:19, Sebastian Tleye <[email protected]> wrote: > Hi Frank, i am currently working improving the implementation of traits in > Pharo,
Excellent! > 2013/5/31 Frank Shearar <[email protected]> >> >> 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. > > > Yes, i think this is a bug, i'll fix it. Thanks! >> 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 :) > > > It looks like a bug, > > a trait using > (S + T @ {#m->#z}) - {#m} > > is the same that a trait using > S + (T @ {#m->#z} - {#m}) > > it seems it is not respecting parentheses... Yes, that's exactly it. frank >> >> 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
