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.

Cheers,
Florin

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to