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:

  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"]

> >  2) Why is this better then localizing the definition to the outer
> > method?
>
> > I tend to favor localization. But really that's only b/c lamdas can't
> > be called the same way methods can, so they can't be used as local
> > drop in replacements. This is one of great things about ruby's
> > "ambiguity" between local vars and methods. Eg.
>
> >  class X
> >    def f; 10; end
> >    def g
> >     f = 20  # local override
> >     f
> >    end
> >  end
>
> > Unfortunately we have no simple way to do this using lamdas, which
> > would make this much more useful.
>
> I'm not sure what it would mean to localize the method.  Do you mean
> it would be automatically removed from the class (whether singleton or
> otherwise) when the method returns?  That seems like something more
> suited to an anonymous function.  To have volatile method names like
> that would also be a threading nightmare, I suspect.

Oh no. I mean that the method would actually be defined essentially
like a local variable is. So I don't think there wouldn't be threading
issues because the method isn't accessible outside it's locality
(outer method). You are right though, anonymous function are more
suited. But the problem there is we loose the method/variable
"ambiguity" I mentioned, because we have to invoke lambdas with a
different syntax.

Hmm.. if we could just methodize variables somehow. Maybe we could use
a different defining method? Say, #fn. Eg.

  def x
    f = fn { |z| z + 1 }
    f(2)
  end

  x #=> 3

This is interesting because we could apply it to other type of
variables too, such as globals.

  $int = fn { |n| Integer(n) }
  $int("20")  #=> 20

And it would make my argument in favor of localizing inner defs moot.

T.