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: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Wayne Kelly [EMAIL PROTECTED] Sent: Thursday, 21 February 2008 12:12 AM To: [email protected] 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 [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
