From: dblack@...
Date: 2007-06-03T05:52:46+09:00
Subject: Re: nested methods don't really exist?!

Hi --

On Sun, 3 Jun 2007, Robert Dober wrote:

> On 6/2/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Trans wrote:
>> 
>> >  module N
>> >    def a
>> >      def b
>> >        "foo"
>> >      end
>> >    end
>> >  end
>> >
>> >  class X
>> >    include N
>> >  end
>> >
>> >  X.new.a
>> >
>> > Currently we get:
>> >
>> >  N.instance_methods(false)  #=> ["a", "b"]
>> >  X.instance_methods(false)  #=> []
>> >
>> > But why isn't it:
>> >
>> >  N.instance_methods(false)  #=> ["a"]
>> >  X.instance_methods(false)  #=> ["b"]
>> 
>> I'll give a modified version of my original answer.  If the default is
>> to put the inner def in the same context as the outer def, then the
>> simplest case (no change in context) has the simplest syntax, and it
>> goes from there.  If the default is to put it in the context of
>> self.class at the time of execution, then getting it into the flat
>> context would require more effort.
>> 
>> So I think it just keeps the semantics congruent with the syntax, or
>> something.  One case or the other is going to require class_eval or
>> equivalent, so I guess having the default case be the one where
>> there's no automatic context-switching just keeps it more simple.
>
> This seems however to be the first case I ever have seen where the
> Proxy of the Mixin is not transparent any more.

How about constants:

   module M
     A = 1
     def a
       puts A
     end
   end

   class C
     include M
     A = 2
   end

   C.new.a     # 1

I think def is considered to be part of the business of the module
where it's physically located, kind of in a constant way.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)