I think I''ve tracked down the cause of this scoping bug. The meth2 body
is executed, but unlike the meth1 body, this time a NestedCodeContext is
created. It appears the problem is that RubyHelpers.CreateNestedCodeContext
doesn''t set the parent property of the nested context to the containing
context that is passed to it as a parameter. Adding a new CodeContext
constructor with an extra parent parameter appears to make the problem go away,
at least in my example.
Cheers, Wayne.
________________________________________
From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at
rubyforge.org] On Behalf Of Wayne Kelly [w.kelly at qut.edu.au]
Sent: Thursday, 21 February 2008 12:12 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Towards gems - obscure scoping bug
module A
Default = 42
def A::foo
end
def A::meth1(param = Default)
foo {}
puts ''OK''
end
def A::meth2(param = Default)
puts ''not OK''
foo { foo {} }
end
A::meth1()
A::meth2()
end
---------------------------------------------------------------------------------------------
The first method executes OK, however, the second method fails when trying to
lookup the Default constant for the unspecified param. Even though the body of
the second method is never executed, the mere presence of the nested blocks
causes the context scoping to get screwed up so that the second method appears
to be nested directly within the global scope rather than with the scope of the
module A where the constant is defined.
BTW, these and other errors that I''ve been reporting aren''t
just random bugs, they''re bugs that I''ve come across in my on
going efforts to get gems setup running under IronRuby, so they are on the
critical path to running Rails.
Cheers, Wayne.
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core