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 <[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
