Yo --

David A. Black wrote:

> On Sun, 11 Sep 2005, Devin Mullins wrote:
>
>> (I'm thinking the PickAxe may be wrong? about the private thing since 
>> you can call #moo with an explicit receiver -- sounds more like 
>> public. Can somebody explain?)
>
>
> I think the private thing depends on lexical scope.  Since the nested
> definition of moo is not lexically a top-level definition, it isn't
> privatized.

I'm not sure what you mean. Seems lexically top-level to me -- it's not 
inside a class or module block. That it's inside a method doesn't seem 
to make a difference:

irb(main):001:0> def moo; puts 'moo' end
=> nil
irb(main):002:0> nil.moo
moo
=> nil

You know, if I weren't so !#%@#ing afraid of just reading the @#%#@ing 
source code, I'd've had this question answered by now.

>> #2: When Test.boo is called, moo is defined as an instance method on 
>> Test. Test.boo returns nil, as before, but nil is not a Test object, 
>> so the moo method does not exist.
>
>
> What I find interesting is this:
>
> Nesting a definition inside a class method, and nesting a definition
> inside an instance method, have exactly the same effect: an instance
> method is added to the class.  In one case, this means "self"; in the
> other, it means "self.class".  I'm not sure why it works this way.

> Maybe the real rule is "one lexical layer up", which would take both
> to the class-definition scope that surrounds them.

Precisely. It works like class variables -- it depends solely on the 
*lexical* scope of the method definition. You could have written:

class D
  def bee
    def mee
      puts "mee"
    end
  end
end
module SomeOtherModule
  def D.boo
    def moo
      puts "moo"
    end
  end
end

  D.boo
  d = D.new
  d.bee

  p (D.instance_methods - D.superclass.instance_methods) # includes only 
mee & bee
  p SomeOtherModule.instance_methods #includes only moo

And yes, it is interesting. :)

Devin