# Towards gems - obscure scoping bug

**URL:** <https://www.ruby-forum.com/t/towards-gems-obscure-scoping-bug/129669>\
**Category:** IronRuby\
**Created:** [February 20, 2008, 3:15pm UTC](https://www.ruby-forum.com/t/towards-gems-obscure-scoping-bug/129669 "2008-02-20T15:15:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Wayne\_K](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@Wayne\_K](https://www.ruby-forum.com/u/Wayne_K)\
**Post date:** [February 20, 2008, 3:15pm UTC](https://www.ruby-forum.com/t/towards-gems-obscure-scoping-bug/129669/1 "2008-02-20T15:15:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Wayne\_K](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@Wayne\_K](https://www.ruby-forum.com/u/Wayne_K)\
**Post date:** [February 21, 2008, 1:07am UTC](https://www.ruby-forum.com/t/towards-gems-obscure-scoping-bug/129669/2 "2008-02-21T01:07:47Z")

</div>

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: removed\_email\_address@domain.invalid  
[removed\_email\_address@domain.invalid] On Behalf Of Wayne K.  
[removed\_email\_address@domain.invalid]  
Sent: Thursday, 21 February 2008 12:12 AM  
To: removed\_email\_address@domain.invalid  
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  
removed\_email\_address@domain.invalid  
[http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core)