On 6/1/07, Trans [email protected] wrote:
You’re right on. I think that nested methods are a bad thing to have
especially since invocation of an instance method has side effects on
#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,
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
inner # this should work here as should
self.inner # but what about
class.new.inner # should inner be an instance or singleton
another rescue “Oops”
inner # raises NoMethodError even when called from outer
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
Of course these all sound like use cases which could easily be handled
with a proc and slighly different syntax.
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.
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:
“inner: a regular instance method”
“my_inner: a singleton instance method”
Just anothe way of doing dynamic method definition.
Of course you’d need to do something like carefully remove_method’ing
those inner methods if you wanted to change them.
My blog on Ruby