Just before we get started, we’ll be using the terms lexical scope and dynamic scope a bit. In computer science the term lexical scope is synonymous with static scope.
- lexical or static scope is where name resolution of “part of a program” depends on the location in the source code
- dynamic scope is whether name resolution depends on the program state (dependent on execution context or calling context) when the name is encountered.
What are Closures?
Now establishing the formal definition has been quite an interesting journey, with quite a few sources not quite getting it right. Although the ES3 spec talks about closure, there is no formal definition of what it actually is. The ES5 spec on the other hand does discuss what closure is in two distinct locations.
- “11.1.5 Object Initialiser” section under the section that talks about accessor properties This is the relevant text: (In relation to getters): “Let closure be the result of creating a new Function object as specified in 13.2 with an empty parameter list (that’s getter specific) and body specified by FunctionBody. Pass in the LexicalEnvironment of the running execution context as the Scope.“
- “13 Function Definition” section This is the relevant text: “Let closure be the result of creating a new Function object as specified in 13.2 with parameters specified by FormalParameterList (which are optional) and body specified by FunctionBody. Pass in funcEnv as the Scope.“
Now what are the differences here that stand out?
- We see that 1 specifies a function object with no parameters, and 2 specifies some parameters (optional). So from this we can establish that it’s irrelevant whether arguments are passed or not to create closure.
- 1 also mentions passing in the LexicalEnvironment, where as 2 passes in funcEnv. funcEnv is the result of “calling NewDeclarativeEnvironment passing the running execution context‘s LexicalEnvironment as the argument“. So basically there is no difference.
Now 13.2 just specifies how functions are created. Given an optional parameter list, a body, a LexicalEnvironment specified by Scope, and a Boolean flag (for strict mode (ignore this for the purposes of establishing a formal definition)). Now the Scope mentioned above is the lexical environment of the running execution context (discussed here in depth) at creation time. The Scope is actually [[Scope]] (an internal property).
The ES6 spec draft runs along the same vein.
Lets get abstract
Every problem in computer science is just a more specific problem of a problem we’re familiar with in the natural world. So often it helps to find the abstract problem that we are already familiar with in order to help us understand the more specific problem we are dealing with. Patterns are an example of this. Before I was programming as a profession I was a carpenter. I find just about every problem I deal with in programming I’ve already dealt with in physical carpentry and at a higher level still with physical architecture.
In search of the true formal definition I also looked outside of JavaScript at the language agnostic term, which should just be an abstraction of the JavaScript closure anyway. Yip… Wikipedias definition “In programming languages, a closure (also lexical closure or function closure) is a function or reference to a function together with a referencing environment—a table storing a reference to each of the non-local variables (also called free variables or upvalues) of that function. A closure—unlike a plain function pointer—allows a function to access those non-local variables even when invoked outside its immediate lexical scope.“
My abstract formal definition
A closure is a function containing a reference to the lexical (static) environment via the function objects internal [[Scope]] property (ES5 spec 13.2.9) that it is defined within at creation time, not call time (ES5 spec 13.2.1). The closure is closed over it’s parent lexical environment and all of it’s properties. You can access these properties as variables, but not as properties, because you don’t have access to the internal [[Scope]] property directly in order to reference it’s properties. So this example fails. More correctly (ES5 spec 8.6.2) “Of the standard built-in ECMAScript objects, only Function objects implement [[Scope]].“
var outerObjectLiteral = {
x: 10,
foo: function () {
console.log(x); // ReferenceError: x is not defined obviously
},
invokeMe: function (funArg) {
var x = 20;
funArg();
}
};
outerObjectLiteral.invokeMe(outerObjectLiteral.foo);
See here for an explanation on the differences between properties and variables. That’s basically it. Of course there are many ways we can use a closure and that’s often where confusion creeps in about what a closure actually is and is not. Feel free to bring your perspective on this in the comments section below.
When is a closure born?
So lets get this closure closing over something. JavaScript addresses the funarg problem with closure.
var x = 10;
var outerObjectLiteral = {
foo: function () {
// Because our internal [[Scope]] property now has a property (more specifically a free variable) x, we can access it directly.
console.log(x); // Writes 10 to the console.
},
invokeMe: function (funArg) {
var x = 20;
funArg();
}
};
outerObjectLiteral.invokeMe(outerObjectLiteral.foo);
The closure is created on line 13. Now at line 9 we have access to the closed over lexical environment. When we print x on line 7, we get 10 which is the value of x on [[Scope]] that our closure was statically bound to at function object creation time (not the dynamically scoped x = 20). Now of course you can change the value of the free variable x and it’ll be reflected where ever you use the closed over variable because the closure was bound to the free variable x, not the value of the free variable x.
This is what you’ll see in Chrome Dev Tools when execution is on line 10. Bear in mind though that both foo and invokeMe closures were created at line 13.
Now I’m going to attempt to explain what the structure looks like in a simplified form with a simple hash. I don’t know how it’s actually implemented in the varius EcmaScript implementations, but I do know what the specification (single source of truth) tells us, it should look something like the following:
////////////////
// pseudocode //
////////////////
foo = closure {
FormalParameterList: {}, // Optional
FunctionBody: <...>,
Environment: { // ES5 10.5 VariableEnvironment's Environment record. This is actually the internal [[Scope]] property (set to the outer lexical environment).
x: 10
}
}
The closure is born when the function is created (“the result of creating a new Function object” as stated above). Not when it’s returned by the outer function (I.E. upwards funarg problem) and not when it’s invoked as Angus Croll mentioned here under the “The [[Scope]] property” section.
Angus quotes the ES5 spec 10.4.3.5-7. On studying this section I’m pretty sure it is meant for the context of actually creating the function object rather than invoking an existing function object. The clauses I’ve detailed above (11.1.5 Object Initialiser and 13 Function Definition), confirm this.
The ES6 spec draft “14.1.22 Runtime Semantics: Evaluation” also confirms this theory. Although it’s titled Runtime Semantics, it has several points that confirm my theory… The so called runtime semantics are the runtime semantics of function object creation rather than function object invocation. As some of the steps specified are FunctionCreate, MakeMethod and MakeConstructor (not FunctionInvoke, InvokeMethod or InvokeConstructor). The ES6 spec draft “14.2.17 Runtime Semantics: Evaluation” and also 14.3.8 are similar.
Why do we care about Closure?
Without closures, we wouldn’t have the concept of modules which I’ve discussed in depth here.
Modules are used very heavily in JavaScript both client and server side (think NPM), and for good reason. Until ES6 there is no baked in module system. In ES6 modules become part of the language. The entire Node.js ecosystem exists to install modules via the CommonJS initiative. Modules on the client side most often use the Asynchronous Module Definition (AMD) implementation RequireJS to load modules, but can also use the likes of CommonJS via Browserify, which allows us to load node.js packages in the browser.
As of writing this, the TC39 committee have looked at both the AMD and CommonJS approaches and come up with something completely different for the ES6 module draft spec. Modules provide another mechanism for not allowing secrets to leak into the global object.
Modules are not new. David Parnas wrote a paper titled “On the Criteria To Be Used in Decomposing Systems into Modules” in 1972. This explores the idea of secrets. Design and implementation decisions that should be hidden from the rest of the programme.
Here is an example of the Module pattern that includes both private and public methods. my.moduleMethod has access to private variables outside of it’s VariableEnvironment (the current scope) via the Environment record which references the outer LexicalEnvironment via it’s internal [[Scope]] property.
Information hiding: state and implementation. In JavaScript we don’t have access modifiers, but we don’t need them either. We can hide our secrets with various patterns. Closure is a key concept for many of these patterns. Closure is a key building block for helping us to programme against contract rather than implementation, helping us to form consistent abstractions, giving us the ability to engage with a concept while safely ignoring some of its details. Thus hiding unnecessary complexity from consumers.
I think Steve McConnell explains this very well in his classic “Code Complete” book. Steve uses the house abstraction as his metaphor. “People use abstraction continuously. If you had to deal with individual wood fibers, varnish molecules, and steel molecules every time you used your front door, you’d hardly make it in or out of your house each day. Abstraction is a big part of how we deal with complexity in the real world. Software developers sometimes build systems at the wood-fiber, varnish-molecule, and steel-molecule level. This makes the systems overly complex and intellectually hard to manage. When programmers fail to provide larger programming abstractions, the system itself sometimes fails to make it through the front door. Good programmers create abstractions at the routine-interface level, class-interface level, and package-interface level-in other words, the doorknob level, door level, and house level-and that supports faster and safer programming.“
Encapsulation: you can not look at the details (the internal implementation, the secrets).
Partial function application and Currying: I have a set of posts on this topic. Closure is an integral building block of these constructs. Part 1, Part 2 and Part 3.
Functional JavaScript relies heavily on closure.
Are there any Costs or Gotchas of using Closures?
Of course. You didn’t think you’d get all this expressive power without having to think about how you’re going to use it did you? As we’ve discussed, closures were created to address the funarg problem. In doing that, the closure references the lexical (static) scope of the outer scope. So even once the free variables are out of scope, closure will still reference them if they were saved at function creation time. They can not be garbage collected until the function that references (is closed over) the outer scope has fallen out of scope. I.E. the reference count is 0.
var x = 10;
var noOneLikesMe = 20;
var globalyAccessiblePrivilegedFunction;
function globalyScopedFunction(z) {
var noOneLikesMeInner = 40;
function privilegedFunction() {
return x + z;
}
return privilegedFunction;
}
// This is where privilegedFunction is created.
globalyAccessiblePrivilegedFunction = globalyScopedFunction(30);
// This is where privilegedFunction is applied.
globalyAccessiblePrivilegedFunction();
Now only the free variables that are needed are saved at function creation time. We see that when execution arrives at line 7, the currently scoped closure has the x free variable saved to it, but not z, noOneLikesMe, or noOneLikesMeInner.
When we enter innerFunction on line 10, we see the hidden [[Scope]] property has both the outer scope and the global scope saved to it.
Say for example execution has passed the above code snippet. If the closed over variables can still be referenced by calling globalyAccessiblePrivilegedFunction again, then they can not be garbage collected. This is a frequently abused problem with the upwards funarg problem. If you’ve got hot code that is creating many functions, make sure the functions that are closed over free variables are dropped out of scope as soon as you no longer have a need for them. This way garbage collection can deallocate the memory used by the free variables.
Looking at how the specification would look simplified, we can see that each Environment record inherits what it knows it’s going to need from the Environment record of its lexical parent. This chaining inheritance goes all the way up the lexical hierarchy to the global function object as seen below. In this case the family tree is quite short. Remember this structure is formed at function creation time, not invocation time. the free variables (not their values) are statically baked.
////////////////
// pseudocode //
////////////////
globalyScopedFunction = closure {
FormalParameterList: { // Optional
z: 30 // Values updated at invocation time.
},
FunctionBody: {
var noOneLikesMeInner = 40;
function privilegedFunction() {
return x + z;
}
return privilegedFunction;
},
Environment: { // ES5 10.5 VariableEnvironment's Environment record. This is actually the internal [[Scope]] property (set to the outer lexical environment).
x: 10 // Free variable saved because we know it's going to be used in privilegedFunction.
},
privilegedFunction: = closure {
FormalParameterList: {}, // Optional
FunctionBody: {
return x + z;
},
Environment: { // ES5 10.5 VariableEnvironment's Environment record. This is actually the internal [[Scope]] property (set to the outer lexical environment).
x: 10 // Free variable inherited from the outer Environment.
z: 30 // Formal parameter saved from outer lexical environment.
}
}
}
Scope
I discuss closure here very briefly and how it can be used to create block scoped variables prior to block scoping with the let keyword in ES6, supposed to be officially approved by December 2014. I discuss scoping here in a little more depth.
Closure misunderstandings
Closures are created when a function is returned
“A closure is formed when one of those inner functions is made accessible outside of the function in which it was contained” found here is simply incorrect. There are also a lot of other misconceptions found at that link. I’d advise to read with a bag of salt.
Now we’ve already addressed this one above, but here is an example that confirms that the closure is in fact created at function creation time, not when the inner function is returned. Yes, it does what it looks like it does. Fiddle with it?
(function () {
var lexicallyScopedFunction = function () {
console.log('We\'re in the lexicalyScopedFunction');
};
(function innerClosure() {
lexicallyScopedFunction();
}());
}());
On line 8, we get to see the closure that was created from the execution of line 11.
Closures can create memory leaks
Yes they can, but not if you let the closure go out of scope. Discussed above.
Values of free variables are baked into the Closure
Also untrue. Now I’ve put in-line comments to explain what’s happening here. Fiddle with the below example?
var numberOfFunctionsRequired = 3;
var getLoopPrinter = function () {
var loopCountingFunctions = new Array(numberOfFunctionsRequired);
for (var i = 0; i < numberOfFunctionsRequired; i++) {
loopCountingFunctions[i] = (function printLoopCount() {
// What you see here is that each time this code is run, it prints the last value of the loop counter i.
// Clearly showing that for each new printLoopCount function created and saved to the loopCountingFunctions array,
// the variable i is saved to the Environment record, not the value of the variable i.
console.log(i);
});
}
return loopCountingFunctions;
};
var runLoopPrinter = getLoopPrinter();
runLoopPrinter[0](); // 3
runLoopPrinter[1](); // 3
runLoopPrinter[2](); // 3
An aside… getLoopPrinter is a global function. Once execution is on line 3 you get to see that global functions also have closure… supporting my comments above
Now in the above example, this is probably not what you want to happen, so how do we give each printLoopCount function it’s on value? Well by creating a parameter for each iteration of the loop, each with the new value. Fiddle with the below example?
var numberOfFunctionsRequired = 3;
var getLoopPrinter = function () {
var loopCountingFunctions = new Array(numberOfFunctionsRequired);
for (var i = 0; i < numberOfFunctionsRequired; i++) {
(function (i) {
// Now what happens here is each time the above loop runs this code,
// inside this scope (the scope of this comment) i is a new formal parameter which of course
// gets statically saved to each printLoopCount functions Environment record (or more simply each closure of printLoopCount).
loopCountingFunctions[i] = (function printLoopCount() {
console.log(i);
});
})(i)
}
return loopCountingFunctions;
};
var runLoopPrinter = getLoopPrinter();
runLoopPrinter[0](); // 0
runLoopPrinter[1](); // 1
runLoopPrinter[2](); // 2
As always, let me know your thoughts on this post, any thing you think I may have the wrong handle on, or anything that otherwise stood out.
References and interesting reads
- Wikipedia Scope
- Wikipedia Closure
- Wikipedia Funargs
- Wikipedia Reference Counting
- JavaScript Patterns by Stoyan Stefanov
- JavaScript The Good Parts by Douglas Crockford.
- Understanding JavaScript Closures by Angus Croll
- Explaining JavaScript scope and closures
- EcmaScript 3 Closures by Dmitry Soshnikov
- EcmaScript 5 Lexical environments by Dmitry Soshnikov
Tags: closure, ecmascript, EcmaScript 3, EcmaScript 5, EcmaScript 6, ES3, ES5, es6, functional programming, Garbage Collection, JavaScript, Web
Binarymist 
Leave a comment