Igor Stasenko wrote: > > > 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) > OK, so that explains why they can currently be used as if they are stateful.
> , 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? > The merged OB/O2 case still passes a full system test, so I didn't run into any show-stoppers. Traits that work this way, supported by the tools, would appear to make them applicable to a lot more cases. ...Stan > On 27 February 2010 02:10, Stan Shepherd <[email protected]> > 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571899.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
