Closures Are Not Magic

This page explains closures so that a programmer can understand them – using working JavaScript code. It is not for gurus nor functional programmers.

Closures are not hard to understand once the core concept is grokked. However, they are impossible to understand by reading any academic papers or academically oriented information about them!

This article is intended for programmers with some programming experience in a main-stream language, and who can read the following JavaScript function:

An Example of a Closure

Two one sentence summaries:

• a closure is the local variables for a function – kept alive after the function has returned, or
• a closure is a stack-frame which is not deallocated when the function returns. (as if a ‘stack-frame’ were malloc’ed instead of being on the stack!)

The following code returns a reference to a function:

Most JavaScript programmers will understand how a reference to a function is returned to a variable in the above code. If you don’t, then you need to before you can learn closures. A C programmer would think of the function as returning a pointer to a function, and that the variables sayAlert and say2 were each a pointer to a function.

There is a critical difference between a C pointer to a function, and a JavaScript reference to a function. In JavaScript, you can think of a function reference variable as having both a pointer to a function as well as a hidden pointer to a closure.

The above code has a closure because the anonymous function function() { alert(text); } is declared inside another function, sayHello2() in this example. In JavaScript, if you use the function keyword inside another function, you are creating a closure.

In C, and most other common languages after a function returns, all the local variables are no longer accessable because the stack-frame is destroyed.

In JavaScript, if you declare a function within another function, then the local variables can remain accessable after returning from the function you called. This is demonstrated above, because we call the function say2(); after we have returned from sayHello2(). Notice that the code that we call references the variable text, which was a local variable of the functionsayHello2().

Click the button above to get JavaScript to print out the code for the anonymous function. You can see that the code refers to the variable text. The anonymous function can referencetext which holds the value ’Jane’ because the local variables of sayHello2() are kept in a closure.

The magic is that in JavaScript a function reference also has a secret reference to the closure it was created in – similar to how delegates are a method pointer plus a secret reference to an object.

More examples

For some reason closures seem really hard to understand when you read about them, but when you see some examples you can click to how they work (it took me a while).
I recommend working through the examples carefully until you understand how they work. If you start using closures without fully understanding how they work, you would soon create some very wierd bugs!

Example 3

This example shows that the local variables are not copied – they are kept by reference. It is kind of like keeping a stack-frame in memory when the outer function exits!

Example 4

All three global functions have a common reference to the same closure because they are all declared within a single call to setupSomeGlobals().

The three functions have shared access to the same closure – the local variables of setupSomeGlobals() when the three functions were defined.

Note that in the above example, if you click setupSomeGlobals() again, then a new closure (stack-frame!) is created. The old gAlertNumber, gIncreaseNumber, gSetNumber variables are overwritten with new functions that have the new closure. (In JavaScript, whenever you declare a function inside another function, the inside function(s) is/are recreated again eachtime the outside function is called.)

Example 5

This one is a real gotcha for many people, so you need to understand it.
Be very careful if you are defining a function within a loop: the local variables from the closure do not act as you might first think.

The line result.push( function() {alert(item + ‘ ‘ + list[i])} adds a reference to an anonymous function three times to the result array. If you are not so familiar with anonymous functions think of it like:

Note that when you run the example, “item3 undefined” is alerted three times! This is because just like previous examples, there is only one closure for the local variables forbuildList. When the anonymous functions are called on the line fnlist[j](); they all use the same single closure, and they use the current value for i and item within that one closure (where i has a value of 3 because the loop had completed, and item has a value of ’item3′).

Example 6

This example shows that the closure contains any local variables that were declared inside the outer function before it exited. Note that the variable alice is actually declared after the anonymous function. The anonymous function is declared first: and when that function is called it can access the alice variable because alice is in the closure.
Also sayAlice()(); just directly calls the function reference returned from sayAlice() - it is exactly the same as what was done previously, but without the temp variable.

Tricky: note also that the sayAlert variable is also inside the closure, and could be accessed by any other function that might be declared within sayAlice() or it could be accessed recursively within the inside function.

Example 7

This final example shows that each call creates a separate closure for the local variables. There is not a single closure per function declaration. There is a closure for each call to a function.

Summary

If everything seems completely unclear then the best thing to do is to play with the examples. Reading an explanation is much harder than understanding examples.
My explanations of closures and stack-frames etc are not technically correct – they are gross simplifications intended to help understanding. Once the basic idea is grokked, you can pick up the details later.

Final points:

• Whenever you use function inside another function, a closure is used.
• Whenever you use eval() inside a function, a closure is used. The text you eval can reference local variables of the function, and within eval you can even create new local variables by using eval(‘var foo = …
• When you use Function() inside a function, it does not create a closure. (The new function cannot reference the local variables of the function calling Function()).
• A closure in JavaScript is like keeping a copy of the all the local variables, just as they were when a function exited.
• It is probably best to think that a closure is always created just on entry to a function, and the local variables are added to that closure.
• A new set of local variables is kept every time a function with a closure is called (Given that the function contains a function declaration inside it, and a reference to that inside function is either returned or an external reference is kept for it in some way).
• Two functions might look like they have the same source text, but have completely different behaviour because of their ‘hidden’ closure. I don’t think JavaScript code can actually find out if a function reference has a closure or not.
• If you are trying to do any dynamic source code modifications ( for example: myFunction = Function(myFunction.toString().replace(/Hello/,’Hola’)); ), it won’t work if myFunction is a closure (Of course, you would never even think of doing source code string substitution at runtime, but…).
• It is possible to get function declarations within function declarations within functions – and you can get closures at more than one level.
• I think normally a closure is the term for both the function along with the variables that are captured. Note that I do not use that definition in this article!
• I suspect that closures in JavaScript differ from those normally found in functional languages.

Links

• TrimBreakpoint is a tricky use of closures to let you inspect local variables for a function from a popup breakpoint window.
• Douglas Crockford’s simulated private attributes and private methods for an object, using closures.
• A great explanation of how closures can cause memory leaks in IE if you are not careful.

Thanks

If you have just learnt closures (here or elsewhere!), then I am interested in any feedback from you about any changes you might suggest that could make this article clearer. Send an email to morrisjohns.com (morris_closure @). Please note that I am not a guru on JavaScript – nor on closures.

Thanks for reading.

–

These are the details that I’ve been able to dig up. It’s worth noting first that although JavaScript is usually considered to be interpreted and run on a VM, this isn’t really the case with the modern interpreters, which tend to compile the source directly into machine code (with the exception of IE).

Chrome : V8 Engine

V8 has a compilation cache. This stores compiled JavaScript using a hash of the source for up to 5 garbage collections. This means that two identical pieces of source code will share a cache entry in memory regardless of how they were included. This cache is not cleared when pages are reloaded.

Source

Opera : Carakan Engine

In practice this means that whenever a script program is about to be compiled, whose source code is identical to that of some other program that was recently compiled, we reuse the previous output from the compiler and skip the compilation step entirely. This cache is quite effective in typical browsing scenarios where one loads page after page from the same site, such as different news articles from a news service, since each page often loads the same, sometimes very large, script library.

Therefore JavaScript is cached across page reloads, two requests to the same script will not result in re-compilation.

Source

Firefox : SpiderMonkey Engine

SpiderMonkey uses Nanojit as its native back-end, a JIT compiler. The process of compiling the machine code can be seen here. In short, it appears to recompile scripts as they are loaded. However, ifwe take a closer look at the internals of Nanojit we see that the higher level monitor jstracer, which is used to track compilation can transition through three stages during compilation, providing a benefit to Nanojit:

The trace monitor’s initial state is monitoring. This means that spidermonkey is interpreting bytecode. Every time spidermonkey interprets a backward-jump bytecode, the monitor makes note of the number of times the jump-target program-counter (PC) value has been jumped-to. This number is called the hit count for the PC. If the hit count of a particular PC reaches a threshold value, the target is considered hot.

When the monitor decides a target PC is hot, it looks in a hashtable of fragments to see if there is a fragment holding native code for that target PC. If it finds such a fragment, it transitions to executing mode. Otherwise it transitions to recording mode.

This means that for hot fragments of code the native code is cached. Meaning that will not need to be recompiled. It is not made clear is these hashed native sections are retained between page refreshes. But I would assume that they are. If anyone can find supporting evidence for this then excellent.

EDIT: It’s been pointed out that Mozilla developer Boris Zbarsky has stated that Gecko does not cache compiled scripts yet. Taken from this SO answer.

Safari : JavaScriptCore/SquirelFish Engine

I think that the best answer for this implementation has already been given by someone else.

We don’t currently cache the bytecode (or the native code). It is an
option we have considered, however, currently, code generation is a
trivial portion of JS execution time (< 2%), so we’re not pursuing
this at the moment.

This was written by Maciej Stachowiak, the lead developer of Safari. So I think we can take that to be true.

I was unable to find any other information but you can read more about the speed improvements of the latest SquirrelFish Extreme engine here, or browse the source code here if you’re feeling adventurous.

IE : Chakra Engine

There is no current information regarding IE9′s JavaScript Engine (Chakra) in this field. If anyone knows anything, please comment.

This is quite unofficial, but for IE’s older engine implementations, Eric Lippert (a MS developer of JScript) states in a blog reply here that:

JScript Classic acts like a compiled language in the sense that before any JScript Classic program runs, we fully syntax check the code, generate a full parse tree, and generate a bytecode. We then run the bytecode through a bytecode interpreter. In that sense, JScript is every bit as “compiled” as Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level than the JVM bytecode — the JScript Classic bytecode language is little more than a linearization of the parse tree, whereas the JVM bytecode is clearly intended to operate on a low-level stack machine.

This suggests that the bytecode does not persist in any way, and thus bytecode is not cached.

http://stackoverflow.com/questions/1096907/do-browsers-parse-javascript-on-every-page-load/9261355#9261355

	jQuery.fn.parentByAttribute = function parentByAttribute(sAttribute, sValue) {
		if (this.length>0) {
			if (sValue) {
				return this.first().parents("["+sAttribute+"='"+sValue+"']").get(0);
			} else {
				return this.first().parents("["+sAttribute+"]").get(0);
			}
		}
	};

*********

	 * Example:
	 * <pre>
	 *   getObject()            -- returns the context object (either param or window)
	 *   getObject("a.b.C")     -- will only try to get a.b.C and return undefined if not found.
	 *   getObject("a.b.C", 0)  -- will create a, b, and C in that order if they don't exists
	 *   getObject("a.b.c", 1)  -- will create a and b, but not C.
	 * </pre>

	getObject = function getObject(sName, iNoCreates, oContext) {
		var oObject = oContext || _window,
			aNames = (sName || "").split("."),
			l = aNames.length,
			iEndCreate = isNaN(iNoCreates) ? 0 : l - iNoCreates;

		for (var i=0; oObject && i<l; i++) {
			if (!oObject[aNames[i]] && i<iEndCreate ) {
				oObject[aNames[i]] = {};
			}
			oObject = oObject[aNames[i]];
		}
		return oObject;

	};

***********

* Shortcut for document.getElementById(...)

	var domByIdInternal = function(sId, oWindow) {

		if (!oWindow) {
			oWindow = window;
		}
		if (!sId || sId=="") {
			return null;
		}

		var oDomRef = oWindow.document.getElementById(sId);

		// IE also returns the element with the name or id whatever is first
		// => the following line makes sure that this was the id
		if (oDomRef && oDomRef.id == sId) {
			return oDomRef;
		}

		// otherwise try to lookup the name
		var oRefs = oWindow.document.getElementsByName(sId);
		for (var i=0;i<oRefs.length;i++) {
			oDomRef = oRefs[i];
			if (oDomRef && oDomRef.id == sId) {
				return oDomRef;
			}
		}

		return null;

	};

************

//is there tabindex?

hasTabIndex = function hasTabIndex() {
		var oDomRef = this.get(0);
		var iTabIndex = jQuery(oDomRef).attr("tabIndex");
		return !isNaN(iTabIndex) && iTabIndex >= 0;
	};

****************

	var UriParams = function(sUri) {
		this.mParams = {};
		var sQueryString = sUri || window.document.location.href;
		if ( sQueryString.indexOf('#') >= 0 ) {
			sQueryString = sQueryString.slice(0, sQueryString.indexOf('#'));
		}
		if(sQueryString.indexOf("?") >= 0){
			sQueryString = sQueryString.slice(sQueryString.indexOf("?") + 1);
			var aParameters = sQueryString.split("&"),
				mParameters = {},
				aParameter,
				sName,
				sValue;
			for(var i=0; i<aParameters.length; i++){
				aParameter = aParameters[i].split("=");
				sName = decodeURIComponent(aParameter[0]);
				sValue = aParameter.length > 1 ? decodeURIComponent(aParameter[1].replace(/\+/g,' ')) : "";
				if(sName){
					if(!Object.prototype.hasOwnProperty.call(mParameters, sName)){
						mParameters[sName] = [];
					}
					mParameters[sName].push(sValue);
				}
			}
			this.mParams = mParameters;
		}
	};

************

* Open chrome://flags
* Find Shadow DOM flag and click to enable
* Restart Chrome
* Navigate to http://jsfiddle.net/dglazkov/eQSZd/embedded/result/
* If you see SHADOW DOM IS WORKING, you’re all set.
* Otherwise, go “hmmmm…” and try again?

This first drop supports:
* creating a shadow root (vendor-prefixed, so WebKitShadowRoot)
* one shadow root per element
* most of the event/CSS plumbing

Coming soon:
* <content> and <shadow> element support
* multiple shadow roots per element
* and more!

Try it, and don’t forget to file bugs at https://bugs.webkit.org/enter_bug.cgi?product=WebKit&blocked=63606&component=HTML%20DOM

http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html

Link to article