On Tue, Oct 26, 2010 at 3:26 PM, Florin Mateoc
<fmateoc@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