Understand closures

In the class, he defines a closure as follows:

"We have said that functions are values, but we have not been precise about what that value exactly is. We now explain that a function value has two parts, the code for the function (obviously) and the environment that was current when we created the function. These two parts really do form a “pair” but we put “pair” in quotation marks because it is not an ML pair, just something with two parts. You cannot access the parts of the “pair” separately; all you can do is call the function. This call uses both parts because it evaluates the code part using the environment part.

This “pair” is called a function closure or just closure. The reason is that while the code itself can have free variables (variables that are not bound inside the code so they need to be bound by some outer environment), the closure carries with it an environment that provides all these bindings. So the closure overall is “closed” — it has everything it needs to produce a function result given a function argument."

(section course notes: https://d396qusza40orc.cloudfront.net/proglang/lecture_slide...)

Java only allows 'final' or immutable variables to be passed into closures. This prevents the value from changing and ensures that the compiler catches the problem if you try to pass a changing value into a closure.

To try to put a name on what you've observed, what you're really doing is emulating a call-by-name [1] evaluation strategy, in which you want an expression to be evaluated at the time the asynchronous callee needs the value, rather than when the call is scheduled. Some languages (like Scala) have specific syntax for this, but in other languages, you emulate this behavior by wrapping the expression in a function, and calling that function when you want the expression to be evaluated.

The closure facilitates this by letting you bind names in the expression to variables in the outer scope. These variables aren't available to the actual caller of the function (somewhere in setTimeout's implementation) to be bound to the function's arguments in the "normal" way. So really, you find that there are two basic ways to make variables available to a function's scope: the invoker of the function can bind the function's arguments to values in its scope, or the function can bind variables from any of the scopes that enclose it, namely all of the enclosing functions. (There's also `this`, but that's another story.)

A much better use case is if you want an event handler to have access to the state of the object that registered it. If you bind the event handler within that object's scope, you can refer to that state within the event handler, and whenever it fires, the current value of state will available from the enclosing scope. This comes up all the time for me when writing Backbone apps. When doing this kind of stuff, be sure to understand thoroughly how Javascript's `this` works (ugh...).

Also, when designing recursive algorithms, closures give the innermost nested layers of your algorithm access to variables from outer scopes, reducing the need to awkwardly pass in parameters that don't change between inner function invocations.

Closures are just the tip of the iceberg. Other concepts like higher-order functions, decorators, and combinators are also really powerful. I highly recommend the most excellent Javascript Allongé [2] for anyone who truly wants to understand this stuff, and learn how to really make it work for them.

[1] http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_nam...

[2] https://leanpub.com/javascript-allonge/read

All of the confusion in JavaScript comes from the fact that the enclosing environment is generally bound to the nearest function call. This is not what people expect, and it is not what happens in other languages with closures.

If versioning JavaScript features was not such a mess, it wouldn't happen in JavaScript either. Everyone would learn to declare variables with let instead of var, and closures would just work sanely. Unfortunately you need to use JavaScript 1.7 to get that feature, and browsers assume that you're using JavaScript 1.5 unless you jump through hoops to get there.

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_... for more.

[1] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

[2] http://unscriptable.com/2011/10/02/closures-for-dummies-or-w...

[3] http://benalman.com/news/2010/11/immediately-invoked-functio...

It works because it's a brand new variable. JavaScript is a pass by value language, and the i inside the function is a different chunk of memory than the i from the loop

The post doesn't really explain closures, and the examples really just show what happens when you mutate variables, in this case in a for-loop - they change value!

The last example also shows how javascript has function scope as opposed to block scope, i.e. the variable "string" might as well have been declared outside the for-loop.

It's overkill to if you just want a working definition, but is instrumental in understanding the underlying concepts that power closures.

1. http://jibbering.com/faq/notes/closures/