Issue #5777 has been updated by Shugo Maeda.


George MacKerron wrote:
> Yehuda, thanks for the response. I understand that the lookup rules were changed between 1.9.1 and 1.9.2 -- that's not the issue I'm raising.
> 
> What I find strange is that class_eval in 1.9.2+ interprets the exact same code differently according to whether it's provided as a block or as a string -- as seen in the first test case in my initial report.
> 
> Is this really what's intended? If so, then at the very least the documentation for class_eval might mention it.

It is intended behavior, because a block closes the environment, but a string doesn't.
I've fixed the documentation.
----------------------------------------
Bug #5777: class_eval/module_eval works differently when given a string than when given a block in 1.9.2 and 1.9.3
https://bugs.ruby-lang.org/issues/5777#change-24640

Author: George MacKerron
Status: Closed
Priority: Normal
Assignee: Shugo Maeda
Category: 
Target version: 
ruby -v: ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.1]


class_eval/module_eval works differently when passed code as a string than when passed the same code as a block in 1.9.2/1.9.3. 

In particular, constant lookup appears to vary. Here's a very short test case (this is on a Mac on 1.9.2, but I see the same behaviour on Ubuntu and on 1.9.3p0):

dyn200:~ George$ ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.1]
dyn200:~ George$ irb
irb(main):001:0> class A; X = 1; end; A.class_eval 'X'
=> 1
irb(main):002:0> class B; Y = 1; end; B.class_eval { Y }
NameError: uninitialized constant Class::Y
	from (irb):2:in `block in irb_binding'
	from (irb):2:in `class_eval'
	from (irb):2
	from /Users/George/.rbenv/versions/1.9.2-p290/bin/irb:12:in `<main>'


It appears this was not the case in 1.9.1:

george@production:~$ ruby -v
ruby 1.9.1p378 (2010-01-10 revision 26273) [i486-linux]
george@production:~$ irb
irb(main):001:0> class A; X = 1; end; A.class_eval 'X'
=> 1
irb(main):002:0> class B; Y = 1; end; B.class_eval { Y }
=> 1


It seems unlikely this in intentional (?) -- it certainly violated 'least surprise' for me!

I note also that with const_get it works OK either way, including with a block:

irb(main):001:0> class B; Y = 1; end; B.class_eval { const_get :Y }
=> 1



-- 
http://bugs.ruby-lang.org/