On Jun 1, 6:57 pm, "Rick DeNatale" <rick.denat... / gmail.com> wrote:

> Trans, you lost me there on several counts.
>
> What would it mean for an inner def to be local to an inner def.
>
> I get the idea that you mean that, in analogy to local variables we'd see this:
>
> class A
>
>    def outer
>        def inner
>            ...
>        end
>        inner # this should work here as should
>        self.inner  # but what about
>        class.new.inner # should inner be an instance or singleton method?
>        another rescue "Oops"
>        method(:inner)
>    end
>
>    private
>    def another
>       inner  # raises NoMethodError even when called from outer
>    end
> end
>
> A.new.inner.call   # And should this work?
>
> So I think the basic meaning is that the inner method would only live
> during the execution of the outer method, and would be inaccessible
> outside of that stack frame, except maybe if they were returned or
> passed.
>
> Of course these all sound like use cases which could easily be handled
> with a proc and slighly different syntax.

Right. Inner def would be treated just like local variables. There
would be no instance access, private or public. They would be very
much like procs. But procs differ in a couple of ways, most notably in
that they have a different call syntax. With local methods one could
do:

  class X
    def a
      "foo"
    end
    def b
      def a
        "bar"
      end
      a
    end
  end

  X.new.b => "bar"

The point being that the local method can serve in place of the
instance methods without subsequent syntax changes to the call --
something lambdas don't allow (ie. the call to #a would have to be
changed to a.call or a[] instead).

> > they really aren't very useful --being little more than a shortcut for
> > (class << self; self; end).define_method().
>
> Of course this wouldn't work since define_method is private.

Common mistake on my part. Making #define_method public is not beyond
me ;) But I am wrong about the shortcut. I thought the inner defs were
creating singleton methods. I'm a bit startled to see they are
defining instance methods, and pinned to the module/class in which the
outer method is defined --not self.class. (Try it with a module to see
what I mean.) Inner defs are a rather new feature AFAIK, I wonder how
that decision was arrived at? Is there some reason for this, or is it
just a stop gag measure toward the eventual behavior in Ruby 2.0?

> Now as Robert K, points out what really happens is that the inner def
> is "executed" whenever the outer method is, and other than the timing
> it does the same thing as if it were in the class/module context.
>
> Now if one wanted to avoid re-defining such inner methods, one could
> write something like:
>
> class A
>     def outer
>         unless self.class.instance_methods(false).include?(:inner)
>             def inner
>                  "inner: a regular instance method"
>             end
>        end
>         unless singleton_methods(false).include?(:my_inner)
>             def self.my_inner
>                  "my_inner: a singleton instance method"
>             end
>        end
>     end
> end

Could. Though the would not work if the method were defined in an
included module.

T.