Hi Frank, Discussing with DamienC and Stef we agree it's a bug, we will fix it.
2013/6/4 Frank Shearar <[email protected]> > 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 > >
