Skip to Content
The first part of this article series ended with the question, “What happens when we call foo(),” in this code sample?

var foo = function () { // start of outer function
 var counter = 0; return function () { // start of inner function
 counter = counter + 1;
 return counter; // end of inner function
 }
}(); // end of outer function
The outer function is self-invoked immediately after creation (by the () on the last line). After invocation, the outer function returns the inner anonymous function. However, the inner function references a variable, counter, that was defined in the outer function. What happens when the inner function is invoked?
If you were to think of this as C++ or Java code there would be a problem. In C++ or Java, counter would be a local variable to the outer function block. Once the outer function finished executing, counter would be removed from the stack (C/C++), or garbage collected (Java).

As it turns out though, in JavaScript this just works. Repeated invocations to foo() yield:

foo(); // returns: 1
foo(); // returns: 2
foo(); // returns: 3
This works because when an anonymous function is created, it carries the state and scope in which it was created. This is called a closure because the anonymous function “closes around” the variables it uses, holding references to them, and preventing them from being garbage collected. It does not hold copies of the values of the variables, but rather references to the actual variables that were in its scope when it was created.
Big deal, right? Well as it turns out, it is.
One criticism of JavaScript is that it doesn’t support data hiding (like private members in Java or C++). Closures can be used to implement data hiding. Consider this extended counter example:
// Our counter “class”
var counter = function () {
 // create a blank object we will bestow with public methods
 // this is sort of like our class “instance”
 var that = {}; // our hidden private member
 var private_counter_value = 0; // method to increment counter
 var incr = function () {
 private_counter_value++;
 } // method that returns the current counter value
 var getCount = function () {
 return private_counter_value;
 }
 // bestow that with public methods
 that.incr = incr;
 that.getCount = getCount; // return our class “instance”
 return that;
}();
The code creates a “classical” looking counter, with two public methods: incr, and getCount. Since both of these methods contain a reference to private_counter_value, they both create a closure around it. private_counter_value has been successfully hidden since the only way it can be accessed is though the “public” methods that contain references to it. No external code can modify (or even see) private_counter_value directly.

counter.inc()
counter.inc()
alert(counter.getCount()); // displays “2”
It may seem that this counter implementation is more verbose and confusing than the corresponding Java or C++ code. After all, both of those languages have the private, protected, and public keywords that do this automatically. That’s true, but only because we tried to make our counter look and operate like a Java or C++ class. JavaScript’s closures, prototype system (don’t confuse this with the popular JavaScript library of the same name, they are totally different), and duck typing enable you to create all kinds of “classes” that look and behave nothing like Java or C++ classes. JavaScript approach to classes is more general, making it more powerful for some applications.
In the final part of this series, we will look at how closures make asynchronous programming simpler. This is very useful for applications using Ajax, or gears workers.
Aside: Closures are not unique to JavaScript. Functional languages like Lisp have supported them for decades. Most modern dynamic programming languages (Python, Ruby, Perl, etc) support closures.
 
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply