On 6/2/07, Rick DeNatale [email protected] wrote:
class A
[]
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.
Perhaps the OP was, but I think that Robert’s statements are still correct:
Sure was, sure was, I am just with you right now, thanks to your
explanation Rick.
I mean Robert’s as emphasized by Rick, just gotta reread the whole
thread, now that I know what you are talking about 
Thx a lot to both of you.
Robert
On Jun 2, 9:36 am, [email protected] wrote:
to un-constrain it to the outer class. In other words, you can do:
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”]
def g
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.
On Jun 2, 11:47 am, Trans [email protected] wrote:
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).
s/wouldn’t/would/
T.
Trans wrote:
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().
Early on, SICP shows the use of inner methods for abstracting function
behavior but Ruby does not afford the same scoping.
–
James B.
“Simplicity of the language is not what matters, but
simplicity of use.”
- Richard A. O’Keefe in squeak-dev mailing list
Hi –
On Sun, 3 Jun 2007, Trans wrote:
Hi –
self.class.
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 
end
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.
David
Hi –
On Sun, 3 Jun 2007, Robert D. wrote:
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.
How about constants:
module M
A = 1
def a
puts A
end
end
class C
include M
A = 2
end
C.new.a # 1
I think def is considered to be part of the business of the module
where it’s physically located, kind of in a constant way.
David
On 6/2/07, [email protected] [email protected] wrote:
So can anyone explain to me why this behavior was chosen over the
end
Hmm… still a little confusion here. I don;t mean that it would imply
end
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
On 6/2/07, [email protected] [email protected] wrote:
"foo"
Currently we get:
to put the inner def in the same context as the outer def, then the
This seems however to be the first case I ever have seen where the
David
Ah thanks, I was not aware of this case.
Robert
On Jun 2, 4:36 pm, [email protected] wrote:
end
we had this code:
end
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.
In other words, the conciser syntax does the thing that would be
harder to do via normal meta-coding. Good enough reason for me.
(Though I’d still like a way to create local methods via anonymous
functions).
Thanks David,
T.