Hi Frank, i am currently working improving the implementation of traits in Pharo,
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. > > 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... > >> 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 > >
