On May 26, 2004, at 3:00 PM, Dan Doel wrote:

> On Tuesday 25 May 2004 3:41 pm, Mark Hubbart wrote:
>>>    define_method(:foo) { |arg| result = arg }
>>>    foo(5); result # => 5 or ~> NameError?
>>>
>>>    # Or more interesting:
>>>    define_method(:foo) { foo = nil; return true }
>>>    foo # => true or nil or NameError?
>>>    foo # => true or nil?
>>
>> IIUC, the first snippet would give a NameError, the second would 
>> return
>> true twice. That's the way it is now...
>>
>> Why would rescoping rules be changed? Currently, when you call
>> define_method, Class.new, Module.new, etc., the block is rescoped (is
>> that the right word?) and local variables never leak in. So, assuming
>> they don't make a silly change, define_method would be _exactly_
>> orthogonal to def...end:
>
> I don't think that's quite right.
>
> Currently, #define_method is useful for creating methods that capture 
> the
> closure of where it's defined so:
>
> ...
>
> You should get 5 printed out (if my understanding is correct).

I was wrong, as you and someone else pointed out. And I'm pretty sure 
you are right. I hadn't realized that methods defined via blocks 
retained their original binding. That's a _very_ cool thing, and I am 
sure I'll be using it in the future :)

At first, I was thinking that that makes scoping very difficult to 
understand; then I realized that I just need to dump my old 
misunderstandings and figure that the 'self' scope and the current 
binding are only minimally related.

cheers,
Mark