Does Crockford actually suggest this? What page? This would make a lot more sense if there were a final () at the end of your code, meaning that digit_name gets the return value of the outer function, which is the inner function.
–
apsillersAug 9 '12 at 6:04

"I want to avoid using the global variables because they are evil," - No they're not, any more than, say, knives are evil - it's how you use them that matters. (And even then, inappropriate use of globals is...inappropriate - not evil.). But in any case the code you start with to avoid globals immediately creates a global (digit_name).
–
nnnnnnAug 9 '12 at 6:33

@nnnnnn: I was actually citing D.Crockford, I have heard him saying that in two conferences :)
–
NobitaAug 9 '12 at 6:34

1

Yes, Mr Crockford seems to see everything in absolutes. I think grey areas make him nervous. (Not to say that he doesn't have plenty of good advice - the problem is figuring out which bits of advice are just his personal preferences presented as "facts".)
–
nnnnnnAug 9 '12 at 6:42

The distinction involves scope chain with closures. Functions in JavaScript have scope in that they will look up into parent functions for variables that are not declared within the function itself.

When you declare a function inside of a function in JavaScript, that creates a closure. A closure delineates a level of scope.

In the second example, digit_name is set equal to a self-invoked function. That self-invoked function declares the names array and returns an anonymous function.

digit_name thus becomes:

function (n) {
//'names' is available inside this function because 'names' is
//declared outside of this function, one level up the scope chain
return names[n];
}

From your original example, you can see that names is declared one up level up the scope chain from the returned anonymous function (which is now digit_name). When that anonymous function needs names, it travels up the scope chain until it finds the variable declared--in this case, names is found one level up the scope chain.

Regarding efficiency:

The second example is more efficient because names is only declared once--when the self-invoking function fires (i.e., var digit_name = (function() { ... })(); ). When digit_names is called, it will look up the scope chain until it finds names.

In your first example, names gets declared every time digit_names is called, so it is less efficient.

"When you declare a function inside of a function in JavaScript, that creates a closure" - When you call a function that was declared inside another function - each invocation has its own closure...
–
nnnnnnAug 9 '12 at 6:39

Calling a function declared inside of another function doesn't create a new closure. You would be re-using the closure (and each invocation would have its own private scope), but not creating a new one.
–
Elliot B.Aug 9 '12 at 6:48

My apologies, you are correct. What I meant to say was that each time you call the containing function that creates a new closure. I meant that more as a clarification than a correction - you might say that the inner one isn't declared until the containing one is called, but for a newcomer to the concept they might look at the code and think everything is already declared...
–
nnnnnnAug 9 '12 at 7:01

This is not an answer but a clarification in case the given examples still seem confusing.

First, lets clarify. digit_name is not the first function you see in the code. That function is just created to return another function (yes, you can return functions just like you can return numbers or strings or objects, in fact functions are objects):

To simplify the example and illustrate just the idea of closures rather than mix it up with things like self calling functions (which you might not be familiar with yet) you can re-write the code like this:

What you should note is how even though the names array is defined in the digit_name_maker function it is still available in the digit_name function. Basically both functions share this array. That basically is what closures are: variables shared between functions. I like to think of it as a kind of private global variable - it feels like globals in that all the functions have shared access to it but code outside of the closure can't see it.

Simply put, the issue with the first code is that it creates an array upon each call and returns a value from it. It's an overhead due to the fact that you are creating an array everytime you call.

In the second code, it creates a closure that declares only a single array and returns a function that returns a value from that array. Basically, digit_name now carries it's own array instead of making one every call. Your function gets from an existing array from the closure.

On the other hand, closures, if not used properly can and will eat up memory. Closures are usually used to protect inner code from the outer scopes, and usually, implemented with limited access from the outside.

Objects don't get destroyed by the GC unless all references to them are "nulled". In the case of closures, if you can't get in them to kill those inner references, then the objects will not be destroyed by the GC and forever will eat memory.

Actually, when all functions involved in a closure goes out of scope all associated objects gets garbage collected. This is true for all browsers. The only exception are DOM objects that contain circular references in IE.
–
slebetmanAug 9 '12 at 19:47