From: "David A. Black" <dblack@...>
Date: 2004-04-13T11:55:01+09:00
Subject: Re: Two different results for Module.nesting

Hi --

On Tue, 13 Apr 2004, 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's similar to the way constant definitions are scoped:

  irb(main):001:0> module A; X=1; module B; p X; end; end
  1
  => nil
  irb(main):002:0> module A::B; p X; end
  NameError: uninitialized constant A::B::X
	  from (irb):2
  irb(main):003:0> module A::B; p A::X; end
  1

i.e., if you say "module A::B" it's different from entering one level
at a time.  (I don't think this syntax existed in pre-1.8, but I guess
the idea as applied to Module.nesting was similar.)

> I'm interested to hear what other uses people have found for this 
> method.

None.  In fact, until today I didn't know (or had forgotten) that it
existed.


David

-- 
David A. Black
dblack@wobblini.net