On Mar 2, 2010, at 11:12 , Nick S. wrote:
Soapbox on terminology: Though these terms frequently get mixed up,
“closure” merely refers to the ability of code to access locals from the
function it’s defined within regardless of whether or not that enclosing
function has returned (And yes, Ruby’s closures fit this definition, or
at least as far as I can tell).
Wow. Thanks for the attitude after helping you with your problem. Maybe
I should have focused on “like I was expecting it to be” and pointed out
that studying one’s language is tantamount to success.
Soapbox on history:
Maybe you should look at (real) programming languages like smalltalk,
commonlisp, or scheme. Ruby bases a lot of its semantics on languages
like lisp and smalltalk. The following wikipedia entry has code samples
of each (and ruby and many others) describing exactly this problem.
But, “closure” does not imply that it isn’t a function - in fact, in
most languages, closures are full-fledged functions that are,
depending on the language, created with either nested functions and/or
anonymous function literals. I’ve dealt with closures in plenty of
different languages and this is still the first one I’ve come across
where returning from a closure also returned from the function that
invoked the closure and all the way down the stack through the function
it was created within. So no, that’s not how closures necessarily work.
Not only did I not imply that a closure isn’t a function, I didn’t
imply that ruby blocks were not functions (or methods). They are. That
has little to do with this UNLESS you also carry definitional baggage
from other languages.
Also, I’d watch the use of “most” there. Maybe if you said “most
languages I’ve used”…
In most languages I’ve used, closures behave like ruby’s.