Great article, very interesting. Love the beer example! =)

Closures will also be available in php, check this article http://codeutopia.net/blog/2009/02/20/closures-coming-in-php-53-and-thats-a-good-thing/ .

Very well explained. Thanks!

Lucian: I know, I’m looking forward to them :). They should help remove the need for declaring functions just to be used with functions like preg_replace_callback() which is good, as that is one part of PHP I’ve never liked. One notable difference with closures in PHP is you have to explicitly declare all local variables that are to be available in the enclosed function. Unlike Javascript which inherits all local variables of all previous stack-frames.

A clear, informative overview. Well done.

Thanks for great explanation.
“So a closure is a stack-frame that doesn’t go away after a function is complete.” this definition is the best “Closure” definition I have ever seen.

Thank you so much for the great article! The last example is exactly what I was looking for. Big thanks for keeping me from tearing my hair out =)

Excellent grasp of the material, thanks!

Great overview, thanks

I think it would be more accurate to say right up front that our normal notion of a “stack” (as used to hold parameters and local variables) does not exist in languages like JavaScript (and Scheme, etc). Unlike Pascal, Ada, C, C++, Java, etc., JavaScript has only “heap” with garbage collection; all those “stack frames” to hold parameters and local variables are just more objects on the heap. When no more references to each exist, they individually get garbage collected. This means that there is no special “saving the stack frame” after the function has returned for closures…they all just get garbage collected like everything else when all references to it are deleted.

BTW, the only way I ever Grokked this was after watching (on iTunes U) the UC-Berkeley Comp Sci 61A class on Scheme. Except for the EARRRRLY Fortran days with no recursion on CDC supercomputers, I had not experienced a language that wasn’t fundamentally stack-oriented. The class video explained (with pictures) how the “stack frames” are instead “environments” that chain to each other (just like JavaScript objects chain via Prototypes). There is a global environment with the global vars, a new environment for each function (to hold params and local vars), and instead of a stack of frames on a hardware stack, it is a linked list of enviroments on the heap.

Did this make sense?

As a followup comment, it probably also requires explaining right up front that unlike the Pascal…Java languages (where functions are defined at COMPILE-TIME), JavaScript/Scheme/etc languages define functions at RUN-TIME. Because of this, there is always an environment (ala previous comment) that is active at the time of function creation/definition. It is like the call-stack that exists when the code defining the function is executed. [EXCEPT, of course that there is no stack. There is a great way to visualize how the stack is really a tree now, at… http://en.wikipedia.org/wiki/Spaghetti_stack].
This “current environment” chain is saved as a part of the function definition. In Java-like languages this makes no sense because there is no “current stack or environment” at compile time when the function was defined/compiled.

SO, when that function gets called, instead of “pushing” its params/local vars on top of THE stack, it “pushes” it on top of the environment stack that was saved with the function definition…and since it isnt a real(hardware) stack, but actually sitting in Heap, the function can refer to “local variables” of its “outer” function long after that outer function has returned.

nee mohama katla undi

in one line – bottom to top access is possible in javascript, but not the reverse.

actually, that is not the one line to remember. Any language that has nested class/function/procedure definitions has bottom to top but not top to bottom access as you put it. E.G. Algol, Pascal, Ada, Java.

The real difference about JavaScript is that those “upper level” variables you access will still exist after the “upper level” functions have returned/exited! [None of those stack-based languages do that.]

When I try this code, it shows in firefox and chrome 1,2,3,4,5 and not just 5 as mentioned in the lexical scope section… I don’t understand it :-(

—-
var numbers = [1, 2, 3, 4, 5];
for (var i in numbers) { var num = numbers[i]; var anchor = document.createElement(‘A’); anchor.setAttribute(‘href’, ‘#’); anchor.appendChild(document.createTextNode(num)); document.body.appendChild(anchor);

anchor.addEventListener(‘click’, function(event) { alert(‘My number is ‘ + num); event.preventDefault(); }, false); }

Even after all these years (decade of so) of developing in Javascript I still come back to this subject of scope and closures ever so often as it does occasionally bite me in the proverbial.

Good article, well written and a nice reference to refer to when I do feel the need to look this subject over.

 For my understanding this modification should also do the trick in the last example and keep things more readable. It initialises a variable within the closure with the current value of num in the loop .

  anchor.addEventListener(‘click’, function(event) { var eventNumber = num;         alert(‘My number is ‘ + eventNumber);         event.preventDefault();     }, false);

 For my understanding this modification should also do the trick in the last example and keep things more readable. It initialises a variable within the closure with the current value of num in the loop .

  anchor.addEventListener(‘click’, function(event) { var eventNumber = num;         alert(‘My number is ‘ + eventNumber);         event.preventDefault();     }, false);

Thanks for clarifying lexical scoping, the simplest explanations are always the best. I am slowly learning javascript by going through the online book Eloquent Javascript and needed to see some more examples.

For the sake of correctness on the article, I think you should take a look at http://stackoverflow.com/questions/14995018/does-this-example-prove-javascript-is-not-truly-statically-scoped in reference to the “More on Lexical Scoping” section.