[Pharo-project] Smells looking at collections

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 26 19:03:19 EDT 2010


Hi Florin,

On Tue, Oct 26, 2010 at 3:26 PM, Florin Mateoc <fmateoc at gmail.com> wrote:

> On 10/26/2010 2:27 PM, Eliot Miranda wrote:
> >
> > The argument is not over  the utility of stateful traits.  The argument
> is over how to access that state.  The
> > existing Traits implementation allows indirect access to state, where the
> Trait uses accessors that must be
> > implemented by a class using the trait.  This has the disadvantages
> listed by Levente, possibility of accessor
> > selectors clashing with existing protocol, lack of privacy and poorer
> performance.  One possible solution is to do a
> > new traits implementation that supports state, but as discussed
> integration is hard and that could be a lot of work.
> >  There are other solutions to explore that could localise the changes.
> >
> > For example imagine adding some special illegal syntax that a variant of
> the compiler (a compiler mode or a subclass
> > or...) can deal with and using that to reference trait state. Then
> changes are localised to
> > - the compiler (to compile the syntax down onto the relevant inst vars)
> > - class definition/trait composition (to ensure the state inst vars exist
> in the class)
> > - shout (to highlight the new syntax)
> > - the decompiler (so decompiled trait code displays the new syntax for
> trait state access)
> >
> > Another possibility might be a selector privacy hack.  The selectors used
> to access state in a trait are known not to
> > clash in the trait (they ca be so chosen by the trait author not to
> conflict with anything in the trait) but they
> > cannot be guaranteed not to clash with a user of the trait.  So
> post-compile the selectors for the trait's state could
> > be changed to private values (keys that existed only in the method
> dictionary of the trait user).  This doesn't have
> > the performance of direct inst var access, but it solves the clash and
> privacy issues.
> >
> > And I expect there are other solutions too.
> >
> > In summary don't argue for or against stateful traits, instead think
> about how to add state to traits whilst having
> > the most minimal impact on the rest of the infrastructure.
> >
> > best
> > Eliot
> >
>
> For me, the utility argument is an important one. I don't care about just
> making it work, whether I believe in it or not.
> It's bad enough that I have to do that at my workplace. Then again, they
> are paying me for it.
>

Whatever.  I think you're taking me wrong.  I agree that stateful traits are
more useful than non.  I'm trying to discuss the engineering of them.  Are
you interestined in realising something you want or are you more interested
in scoring points?  Or is getting things to work not what you get paid for?

Eliot


> Cheers,
> Florin
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20101026/0f45fa46/attachment-0001.html>


More information about the Pharo-dev mailing list