On 6/2/07, dblack / wobblini.net <dblack / wobblini.net> wrote:
> 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.

This seems however to be the first case I ever have seen where the
Proxy of the Mixin is not transparent any more.

Robert
>
>
> 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)
>
>


-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw