From: George MacKerron Date: 2011-12-22T07:00:38+09:00 Subject: [ruby-core:41768] [ruby-trunk - 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 Issue #5777 has been updated by George MacKerron. 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. ---------------------------------------- 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 Author: George MacKerron Status: Open Priority: Normal Assignee: 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 `
' 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://redmine.ruby-lang.org