From: Robert Dober <robert.dober@...>
Date: 2007-06-02T20:55:59+09:00
Subject: Re: nested methods don't really exist?!

On 6/2/07, Robert Klemme <shortcutter@googlemail.com> wrote:

> >> #b is defined only after #a has been invoked at least once.  I cannot
> >> think of a scenario where you would want this behavior.
> >
> > There are dynamic behavior scenarios such as memoize where it could be
> > used. But such cases are pretty rare. So I agree. Unless inner defs
> > are local to their outer def, akin to local variables, they really
> > aren't very useful --being little more than a shortcut for (class <<
> > self; self; end).define_method().
>
> That's exactly what they are not.  If at all they are a shortcut for
> self.class.define_method(), i.e. methods defined that way a regular
> instance methods.
>
> I also think that for memoize and such other mechanisms are far more
> useful than current Ruby nested methods.  Actually the current state of
> affairs is a queer mix, because the definition is nested but the scope
> is not (they are neither restricted to the current instance nor to the
> current method).

Robert I think they are:
# vim: sts=2 sw=2 expandtab nu tw=0:

class A
  def a
    def b
      42
    end
  end

end

p A.new.methods.grep(/^b$/)
A.new.b
[]
nested.rb:13: undefined method `b' for #<A:0xb7e337a0> (NoMethodError)

Did you overlook David's post?
I get exactly the same behavior than he does on a 1.8.5 Zenwalk
I have the impression that OP got the victim of a "leftover" in his irb session.

Cheers
Robert

 Maybe that is the major reason for them not being too
> useful.
>
> Kind regards
>
>         robert
>
>


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