From: Brian Marick <marick@...>
Date: 2004-04-13T23:49:46+09:00
Subject: Re: Two different results for Module.nesting


On Apr 12, 2004, at 9:32 PM, Chad Fowler wrote:

>
> On 12/4/2004, at 9:26 PM, why the lucky stiff wrote:
>
>> Brian Marick wrote:
>>
>>> Consider this:
>>>
>>>   module M1
>>>     module M2
>>>       class C
>>>         puts Module.nesting.inspect
>>>       end
>>>     end
>>>   end
>>>
>>> It produces  [M1::M2::C, M1::M2, M1], which I expected.
>>>
>>> Now try this:
>>>
>>>    M1::M2::C.class_eval("Module.nesting")
>>>
>>> It produces [M1::M2::C], which I did not expect. Why the difference? 
>>> Thanks.
>>
>> It's returning the proper nesting.  But as you haven't opened each of 
>> the Modules individually to reach the C const, Module::nesting isn't 
>> returning them each individual.
>>
>> Let's illustrate:
>>
>>  module M1::M2
>>    class C
>>      puts Module.nesting.inspect
>>    end
>>  end
>>  #=> [M1::M2::C, M1::M2]
>>
>>
>
> This strikes me as being a bit unintuitive, though I don't ever really 
> need it so I'm not too bothered. :)

It seems unintuitive to me as well. I thought it would tell me about 
the runtime module-nesting structure of the program, not about the 
syntax by which I'm talking about that structure.


> It appears that this behavior is a remnant of the way Ruby is parsed 
> (or, more correctly, how it's eval(.c)uated).  Brian, were you using 
> this for your automock thing?

I came across it while fiddling around with automock.
<http://www.testing.com/cgi-bin/blog/2004/04/12#automock>
But I didn't have to use it.

-----
Brian Marick
Consulting, training, and contracting
Mostly on agile methods with a testing slant
www.testing.com, www.testing.com/cgi-bin/blog