[Pharo-dev] Trait exclusions

Sebastian Tleye stleye at gmail.com
Tue Jun 4 09:34:31 EDT 2013


Hi Frank,

Discussing with DamienC and Stef we agree it's a bug, we will fix it.


2013/6/4 Frank Shearar <frank.shearar at gmail.com>

> On 4 June 2013 10:19, Sebastian Tleye <stleye at gmail.com> wrote:
> > Hi Frank, i am currently working improving the implementation of traits
> in
> > Pharo,
>
> Excellent!
>
> > 2013/5/31 Frank Shearar <frank.shearar at gmail.com>
> >>
> >> On 31 May 2013 12:32, Stéphane Ducasse <stephane.ducasse at inria.fr>
> wrote:
> >> >
> >> > On May 31, 2013, at 1:28 PM, Frank Shearar <frank.shearar at gmail.com>
> >> > wrote:
> >> >
> >> >> On 31 May 2013 12:01, Damien Cassou <damien.cassou at gmail.com> wrote:
> >> >>> Hi Frank,
> >> >>>
> >> >>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar
> >> >>> <frank.shearar at 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.
> >
> >
> >  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130604/6673f31d/attachment.html>


More information about the Pharo-dev mailing list