On a second thought, i think this is not really necessary. Traits can be reformulated to be purely a method source holders, not holders of compiled methods. (And btw, this is actually true, due to the latest changes in traits, because of super sends issues and #methodClass), we only need to push it a little further and get rid of useless limitations. The point is, that all trait methods should _always_ be compiled in the scope of the class to which it applied. Because, for any variable name, which not declared explicitly in the method's scope, we can't tell anything about it, until we apply this method to the real class (See the Class>>bindingOf: ) This means that, even if you having the trait method: foo ^ Array new: 10 the binding of 'Array' variable may be different, depending on class where its installed. To check it, you can try following at home: Object subclass: #ZZZZ instanceVariableNames: '' classVariableNames: 'DD' poolDictionaries: '' category: 'ZZZZ' "add new pool variable" ZZZZ classPool at: #Array put: 10. "now add the method" array ^ Array and now evaluate the following: ZZZZ new array ------------- But what makes array ^ Array method any better than array ^ array := 10. in this regard? Nothing. So, why not drop the limitation, and instead of punishing developer for use undeclared vars in trait methods, punish him for use of undeclared variables, when he tries to apply the trait to concrete class, where all such var names should obtain meaning? Then, ultimately, what is the point in storing compiling methods in Trait (not for classes, where it applied). We could just check the syntax, but should not produce any CompiledMethod instances at all. What other problems i don't see here? On 27 February 2010 02:10, Stan Shepherd <stan.shepherd414@gmail.com> wrote:
Igor Stasenko wrote:
One of the ways of introducing a stateful traits is changing the VM object format.
Sounds like it could be very powerful.
As it happens, in the fork healing example, it's the very statelessness of the traits that make it work so simply. By taking out the  check for statefulness when the method is moved to a trait, the trait will quite happily address the several variables in its user classes. This then removes any need for accessors, helper classes for state, initialization, or other attempts to tame the beast.
I wouldn't want to rely on it continuing to work in all conditions, but as a step in a refactoring it seems very handy.
..Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.