Hi --

On Sun, 3 Jun 2007, Trans wrote:

>
>
> On Jun 2, 9:36 am, dbl... / wobblini.net wrote:
>> Hi --
>>
>>
>>
>> On Sat, 2 Jun 2007, Trans wrote:
>>
>>> On Jun 2, 8:41 am, dbl... / wobblini.net wrote:
>>>> Hi --
>>>> They're allowed; they're just not executed until the enclosing method
>>>> is executed.
>>
>>> Okay. I misunderstood (should have read your post more carefully...
>>> actually I should have gotten my coffee first ;)
>>
>>> So can anyone explain to me why this behavior was chosen over the
>>> other possibilities? Namely
>>
>>>  1) Why are they defined in the outer defs namespace and not
>>> self.class.
>>
>> I would guess because it's easier to constrain it to self.class, than
>> to un-constrain it to the outer class.  In other words, you can do:
>>
>>    def a
>>      def c
>>      end
>>      def self.b
>>      end
>>    end
>>
>> but if the def c implied self, you'd have to jump through more hoops
>> to get at the outer class than you do to get *from* the outer class to
>> the singleton class.  (I'm not claiming any great usefulness for this
>> idiom, but I imagine that's why the syntax is optimized for the outer
>> class case.)
>
> Hmm... still a little confusion here. I don;t mean that it would imply
> self, but that it would it would imply self.class. In other words, say
> we had this code:

Yes, I think I misunderstood, and garbled the answer anyway.  So let's
start again :-)

>  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.


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)