Hi --

On Sat, 7 Feb 2009, Mike Gold wrote:

> Mike Gold wrote:
> If all assignments were the same, this would print '3':
>>
>>   eval("a = 3", binding)
>>   puts a
>>
>
> Or even better,
>
>  eval("a = 3", binding)
>  p local_variables  #=> ["a"]
>  p a  #=> undefined local variable or method `a'
>
> We see that the local exists, but because the parser has not seen the "a
> = ..." syntax, we can't access it.

In 1.9 you get:

[]
-:3:in `<main>': undefined local variable or method `a' for
main:Object (NameError)

so I guess that's been changed. The point about rb_method_missing (as
the source of that error message) is interesting, though since it's be
handled by a handler for non-existent methods, and within that handler
it determines that it also isn't a local variable, I think it's
reasonable to say that it can't tell -- or, perhaps more accurately,
it *can* tell that it is neither a (viable) method call nor a
variable, but it can't tell which you meant (hence the wording of the
error message).

There's also this interesting difference. In 1.8, given this code:

eval("a=3")
p a rescue p "undef"
eval("p a")

you get this output:

"undef"
3

whereas in 1.9 the output for the same code is:

"undef"
-:3:in `eval': undefined local variable or method `a'

So the business of having eval always return to the same scope seems
to have been done away with. (I always thought of it as similar to the
phenomenon of having to be drunk again to remember what you did when
drunk :-)


David

-- 
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!