Hi --
>> 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.
···
On Jun 2, 9:36 am, dbl...@wobblini.net wrote:
On Sat, 2 Jun 2007, Trans wrote:
> On Jun 2, 8:41 am, dbl...@wobblini.net wrote:
