I'm new to Javascript and functional paradigms. I really like using closure to keep little bits of state wrapped up safely in a private scope. It's a refreshing change from the song and dance of class worship in Java.
I wrote the following code with the intention of printing 0-9 to the console. It works, but I'm surprised that it does.
I don't understand how the next refers to the returned function for the recursive next() call! Is it related to the "late binding" property of Javascript?
var next = (function() { // begin stateful wrapper function
var current = -1;
return function() { // begin returned function
current += 1;
if (current < 10) {
console.log(current);
next(); // recursive call
} else {
return;
}
}; // end returned function
})(); // immediately call wrapper function
next(); // call returned function to generate output
During execution, how does the recursive next() call already refer to the returned function?
Where can one read about the details of what's going on here?
(Output:)
0
1
2
3
4
5
6
7
8
9
Perhaps you're confused by the outermost function that is being invoked immediately. This serves only to protect current in a variable scope. If we eliminate that, it's probably clearer.
var current = -1;
var next = function() {// This is what would have been returned in the original
current += 1;
if (current < 10) {
console.log(current);
next(); // recursive call
} else {
return;
}
};
next();
Now you have the same as the original code, except that current isn't in its own scope. As you can see, the function is simply assigned to the next variable.
That's exactly what's happening in the original, except that in the original the outer function exists and is immediately invoked. That outer function is a one-time-shot function, and is not assigned to next, though its return value is.
JavaScript doesn't have block scope (yet), but if it did, think of it as being similar to this:
var next;
{ // Create a (fictional) variable scope that has `current` and the function
var current = -1;
next = function() {
current += 1;
if (current < 10) {
console.log(current);
next(); // recursive call
} else {
return;
}
};
}
next();
But since JS doesn't have block scope, but only function scope, we need to emulate this with a function.
We can tweak the original just a little to make it look similar.
var next;
(function() { // Create a variable scope that has `current` and the function
var current = -1;
next = function() {
current += 1;
if (current < 10) {
console.log(current);
next(); // recursive call
} else {
return;
}
};
}());
next();
During execution, how does the recursive next() call already refer to
the returned function?
When you invoke the function to build the function which defines next (at the line with })(); // immediately call wrapper function), you are only returning a function (functions are just another kind of data in JavaScript until invoked) which references the global next variable, not yet utilizing it. The next step (next();) starts the process and by that time, the internal next reference can find the global next definition.
AFAIU, the terminology of "late binding" tends to have to do with the dynamic value of properties, with this being an especially important one.
Access to next is late here in the sense that the function doesn't need to be available at definition time, but rather at invocation time (though the variable next is already known to the function at definition time for the inner function as well, but its value is undefined at that time; the variable would be known to JavaScript even if ALL of your code had been inside a function and the var were set at the end of the block).
(A small note (which you can ignore if it is too much information): It is good practice (and necessary for "strict mode") to define globals like next with var as you have done. JavaScript will treat variable references as globals unless var is used within that scope, but as mentioned, even if all your code had been inside a function and next had been a local variable, its definition with var allows for discovery of that variable anywhere within the closure, even within nested functions (unlike this which is another can of worms).)
Where can one read about the details of what's going on here?
You might find this helpful: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Closures
UPDATE
In reply to a comment:
In JavaScript...
If a function variable (or any kind of variable) is defined with var, it is recognized as undefined (not as a type error) in that scope (including the case where it is defined in the top, global scope), until an assignment is made to give it the function value (so it can be executed or passed around). Likewise with assignments on existing objects such as window.myFunc = function () {};.
If a function is just declared without var like function myName () {}, it is immediately available everywhere in that scope, before or after the declaration. As with var function declarations, it can similarly be treated as data, with the function passed around as data, e.g., for callbacks.
If a function variable is defined as a variable but without a var existing with that name anywhere up to the global scope, e.g., myGlobal = function () {};, even this will not produce errors (and will work like #1 above) unless "strict mode" is in effect, in which case it will produce an error.
Related
I was reading this tutualial on javascriptissexy.com. I followed up until the last example.
function celebrityIDCreator (theCelebrities) {
var i;
var uniqueID = 100;
for (i = 0; i < theCelebrities.length; i++) {
theCelebrities[i]["id"] = function (j) { // the j parametric variable is the i passed in on invocation of this IIFE
return function () {
return uniqueID + j; // each iteration of the for loop passes the current value of i into this IIFE and it saves the correct value to the array
} (); // BY adding () at the end of this function, we are executing it immediately and returning just the value of uniqueID + j, instead of returning a function.
} (i); // immediately invoke the function passing the i variable as a parameter
}
return theCelebrities;
}
var actionCelebs = [{name:"Stallone", id:0}, {name:"Cruise", id:0}, {name:"Willis", id:0}];
var createIdForActionCelebs = celebrityIDCreator (actionCelebs);
var stalloneID = createIdForActionCelebs [0];
console.log(stalloneID.id); // 100
var cruiseID = createIdForActionCelebs [1];
console.log(cruiseID.id); // 101
First, I didn't see an IIFE, or at least in the syntax I am familiar with in which there would be a (function()... with the leading left-side parenthesis. Also,
return function () {
return uniqueID + j; // each iteration of the for loop passes the current value of i into this IIFE and it saves the correct value to the array
} ();
Why these two returns? And if this is meant to be an IIFE doesn't need the surrounding parenthesis? Also, how does not j immediately increment to the length of the array as i did in the previous example? Concerning the line theCelebrities[i]["id"] = function (j) { which accesses the element id of the actionCelebs parameter. Why does that property need initially to be set to 0 for each element.
Previous example
// This example is explained in detail below (just after this code box).
function celebrityIDCreator (theCelebrities) {
var i;
var uniqueID = 100;
for (i = 0; i < theCelebrities.length; i++) {
theCelebrities[i]["id"] = function () {
return uniqueID + i;
}
}
return theCelebrities;
}
var actionCelebs = [{name:"Stallone", id:0}, {name:"Cruise", id:0}, {name:"Willis", id:0}];
var createIdForActionCelebs = celebrityIDCreator (actionCelebs);
var stalloneID = createIdForActionCelebs [0];
console.log(stalloneID.id()); // 103
Here all of the values are set to 103
Answers to your questions:
IIFE stands for Immediately Invoked Function Expression. In JavaScript, function literals occur in one of two forms: (1) full function definition statements, or (2) expressions. A full function definition statement has function as the leading token of the statement, which means that the statement is not an expression, but just a function definition. It effectively causes a local (or global if in global scope) variable to be created in the current scope with a name equal to the function name as given in the function definition statement, and a value equal to a reference to the function:
function myFunction() {}
myFunction();
When function occurs anywhere (not as the first token) inside an expression, the function definition is said to be "expressionized" and does not automatically create any local variable, but can be stored in a variable by assigning it, or called immediately by following it with a pair of parentheses:
var func = function() { return 7; };
alert(func()); // 7
var funcRes = function() { return 3; }();
alert(funcRes); // 3
Strictly speaking, the term IIFE can refer to any context where a function definition is expressionized and then immediately invoked by following it with a pair of parentheses. You can see in your code example that they do this with the function returning uniqueID + j, and they also do it with the function that encloses said function and simply relays its return value to its parent scope, so both qualify as an IIFE.
In my experience, the term IIFE is used most often to refer to an IIFE that comprises an entire statement, and thus the leading left parenthesis is necessary to exressionize the function definition, for example:
(function() {
var localVar = 3;
alert(localVar);
})();
I think that's why you found the code example slightly unexpected. But both of those 2 function definitions in your code example certainly qualify as IIFEs according to the strict definition of what an IIFE is; as long as the function keyword does not occur as the first token in the statement, then it is expressionized, and can be invoked immediately to form an IIFE.
The two returns are simply necessary as part of the design of the code. Admittedly, the whole thing is quite contrived, and there is a much easier way to accomplish the task, namely, a simple loop that loops through the array and assigns the value of the id hash key to a number incrementing from uniqueID, but they're trying to demonstrate IIFEs, I suppose. The inner return expression computes the next id value from uniqueID and j, which are both closured by the inner function, and returns it from the inner IIFE, and then the outer return relays that return value from the outer IIFE back to the celebrityIDCreator function scope, where it can be assigned.
No, IIFEs do not require surrounding parentheses. To expressionize a function, all that is required is that the function keyword not occur as the first token of the statement.
The full process of closuring is as follows: When a function is defined and contains a variable whose identifier does not bind to any local variable (variable declared with var or function parameter), then it closures around the closest ancestral (thinking of the parse tree) local with that same identifier, or the global if it cannot be bound to any ancestral local. The important point is this: It's a variable reference that is captured by the closure, not a variable value.
In the "Previous example" i closures around the local i that lives in the celebrityIDCreator function scope. Importantly, the function is not immediately invoked, but a reference to the function is stored as the actual value of the id hash key. It is invoked later, during printing. That means that when the function is finally invoked, the variable i has already finished looping through the array, and is now retaining its final value, 103. If the function had been invoked immediately, then i would actually be evaluated during the loop and it would resolve to its current value, which would be the correct incrementing value.
In your main code example, j in the inner IIFE is closuring around the function parameter of the outer IIFE, which is temporary and will never be incremented; that parameter j is a distinct variable from the i in celebrityIDCreator function scope, which is never closured. Also, the inner IIFE is being immediately invoked, so it resolves to the variable's current value anyway. So they've actually overdone it here; there are two reasons why the final assigned value is the proper incrementing value and not the max value (103).
Main point: Closures closure around variables, not values.
The id property did not need to be set to 0 initially; that appears to be just a placeholder. It is overwritten (in both your main example and in the "Previous example") when it is assigned in celebrityIDCreator. And since in the "Previous example" it is overwritten not by another number but by a function, it is a little weird. Again, the whole thing is a little contrived (no offense to the authors...), but all the concepts are there.
Heres a sample bit of code, similar to that that gave me grief:
for(var i=0;i<3;i++){
var Proof = true
if (i == 0){
Proof = false
//var CallBack = function(){alert(Proof);}; // true????
var CallBack = function(){alert(i);};
}
}
// Whatever happened to local scope? shouldn't CallBack be undefined now?
CallBack()// alert(3), should be 0?
CallBack isn't undefined, it alerts true or 3, could someone please explain to me what is going on that is making it act like this? is there some local keyword I am missing, or does JS not have scope? I am using no framework, and would appreciate some help on how to sort this out, and do this kind of thing properly...
JavaScript doesn't have block scope at all (yet, see below). All variables are declared throughout the function in which they appear (or throughout the global scope, if they're at global scope).
Assuming the code you've quoted is the only code in its scope, it's exactly the same as this:
var i;
var Proof;
var Callback;
for(i=0;i<3;i++){
Proof = true
if (i == 0){
Proof = false
//CallBack = function(){alert(Proof);}; // true????
CallBack = function(){alert(i);};
}
}
// Whatever happened to local scope? shouldn't CallBack be undefined now?
CallBack()// alert(3), should be 0?
More (on my blog): Poor, misunderstood var
CallBack()// alert(3), should be 0?
No, 3 is correct, because that's the value of i as of when CallBack is called. CallBack is a closure over the context in which it was created. It has an enduring reference to the context (including the i variable), not a copy of what existed when it was created.
If you wanted to get 0 instead, you'd have to have CallBack close over something other than i, something that won't change. The typical way to do that is to use a builder function you pass a value into:
function buildCallBack(index) {
return function() { alert(index); };
}
Then:
CallBack = buildCallBack(i);
The value of i is passed into buildCallBack as the argument index. buildCallBack creates a function closing over the context of that call to buildCallBack and using that index argument. Since that argument's value is never changed, the callback alerts 0 (in this case) rather than 3.
More (on my blog): Closures are not complicated
The reason I said "yet" above is that the next version of the spec (ES6) will introduce new block-scope semantics for the new let and const keywords and block function declarations. var will be unchanged, but if you use let to declare a variable instead, it has block scope rather than function/global scope.
When CallBack is being called, for loop is finished already. So i equals 3.
If you want i to be local, you should write like this:
var CallBack;
for(var i=0;i<3;i++){
(function(index) {
var Proof = true
if (index == 0){
Proof = false
//var CallBack = function(){alert(Proof);}; // true????
CallBack = function(){alert(index);};
}
})(i);
}
CallBack()
Here is a demo
UPDATE
Here is an alternative:
var CallBack;
for(var i=0;i<3;i++){
var Proof = true
if (i == 0){
Proof = false
CallBack = (function(index) {
return function(){alert(index);};
})(i);
}
}
CallBack()
demo
UPDATE 2
EXPLAINATION:
By writing (function(index) {...})(i) we declare an anonymous function and call it immediately (we could also write function(index) {...}(i) but I think the first case is clearer). In javascript, function is also a way to set another scope of variables, so in our case we "remember" the current state of i variable in index variable that is visible only within our anonymous function.
And when the 'CallBack' is called, alert shows 0 because i was equal 0 when that function was called.
I am interested in how the compiler resolves this reference, on the internals. Say we have this code :
function makeConsumer(run_priority,run_object) {
var consumer = function(last_run_action) {
if(!!last_run_action) {
// do something
} else {
var next_to_load = run_priority.shift();
next_to_load.consume = consumer;
run_load_script(next_to_load,run_object);
}
};
return consumer;
}
There is a reference to consumer at the top, and then, before the function has finished being defined, another reference to consumer occurs in the final else block. How is this reference to consumer valid if the original consumer has not even been assigned at the time when the code is execute? I understand that function pushes scope to the top, but is this also true for a function expression assigned to a variable?
Is it possible to create a scenario in which a function references itself via a variable it is assigned to, and that reference is not yet valid? How does javascript make the second reference to consumer refer to the function, when that reference is part of the function that has not even finished being defined?
Is this equivalent to the references used in recursion? And if so, how are they evaluated by the compiler to be valid?
Javascript variable declarations are hoisted to the top. So all of these variables "exist" before they are ever referenced anywhere. So your example is equivalent to this:
function makeConsumer(run_priority,run_object) {
var consumer;
consumer= function(last_run_action) {
var next_to_load;
if(!!last_run_action) {
// do something
} else {
next_to_load = run_priority.shift();
next_to_load.consume = consumer;
run_load_script(next_to_load,run_object);
}
};
return consumer;
}
There's more on hoisting in this question.
So when consumer is referenced in the function definition, the variable has already been declared.
The variable will also not be evaluated till the function runs. So in this case the function will not have to know what consumer is until the function is actually run (which isn't shown in your example.)
I have some code that invokes anonymous functions within a loop, something like this pseudo example:
for (i = 0; i < numCards; i = i + 1) {
card = $('<div>').bind('isPopulated', function (ev) {
var card = $(ev.currentTarget);
....
JSLint reports the error 'Don't make functions within a loop.' I like to keep my code JSLint clean. I know I can move the anonymous function out of the loop and invoke it as a named function. That aside, here's my question:
Would a Javascript interpreter really create an instance of the function per iteration? Or is there really only one function instance "compiled" and the same code is executed repeatedly? That is, does the JSLint "suggestion" to move the function out of the loop actually affect the efficiency of the code?
Partially it depends on whether you're using a function expression or a function declaration. They're different things, they happen at different times, and they have a different effect on the surrounding scope. So let's start with the distinction.
A function expression is a function production where you're using the result as a right-hand value — e.g., you're assigning the result to a variable or property, or passing it into a function as a parameter, etc. These are all function expressions:
setTimeout(function() { ... }, 1000);
var f = function() { ... };
var named = function bar() { ... };
(Don't use that last one — which is called a named function expression — implementations have bugs, particularly IE.)
In contrast, this is a function declaration:
function bar() { ... }
It's stand-alone, you're not using the result as a right-hand value.
The two main differences between them:
Function expressions are evaluated where they're encountered in the program flow. Declarations are evaluated when control enters the containing scope (e.g., the containing function, or the global scope).
The name of the function (if it has one) is defined in the containing scope for a function declaration. It is not for a function expression (barring browser bugs).
Your anonymous functions are function expressions, and so barring the interpreter doing optimization (which it's free to do), they'll get recreated on each loop. So your use is fine if you think implementations will optimize, but breaking it out into a named function has other benefits and — importantly — doesn't cost you anything. Also, see casablanca's answer for a note about why the interpreter may not be able to optimize out recreating the function on each iteration, depending on how deeply it inspects your code.
The bigger issue would be if you used a function declaration in a loop, the body of a conditional, etc.:
function foo() {
for (i = 0; i < limit; ++i) {
function bar() { ... } // <== Don't do this
bar();
}
}
Technically, a close read of the spec's grammar shows it's invalid to do that, although virtually no implementation actually enforces that. What the implemenations do is varied and it's best to stay away from it.
For my money, your best bet is to use a single function declaration, like this:
function foo() {
for (i = 0; i < limit; ++i) {
bar();
}
function bar() {
/* ...do something, possibly using 'i'... */
}
}
You get the same result, there's no possibility that an implementation will create a new function on every loop, you get the benefit of the function having a name, and you don't lose anything.
Would a Javascript interpreter really create an instance of the function per iteration?
It has to because it doesn't know if the function object will be modified elsewhere. Remember that functions are standard JavaScript objects, so they can have properties like any other object. When you do this:
card = $('<div>').bind('isPopulated', function (ev) { ... })
for all you know, bind could modify the object, for example:
function bind(str, fn) {
fn.foo = str;
}
Clearly this would result in wrong behaviour if the function object was shared across all iterations.
The interpreter may actually create a new function object with every iteration, if only because that function might be a closure that needs to capture the current value of any variable in its outer scope.
That's why JSLint wants to scare you away from creating many anonymous functions in a tight loop.
Boo to JSLint. It's like a blunt instrument on the head. A new function object is created each time function is encountered (it is a statement/expression, not declaration -- edit: this is a white lie. See T.J. Crowders answers). Usually this is done in a loop for a closure, etc. The bigger issue is creating false closures.
For instance:
for (var i = 0; i < 10; i++) {
setTimeout(function () {
alert(i)
}, 10)
}
Will result in "odd" behavior. This isn't an issue with "creating a function in a loop so much as not understanding the rules JS uses for variable scopes and closures (variables are not bound in closures, scopes -- execution contexts -- are).
However, you may want to create a closure in a function. Consider this less-surprising code:
for (var i = 0; i < 10; i++) {
setTimeout((function (_i) {
return function () {
alert(_i)
}
})(i), 10)
}
Oh no! I still created a function!
I'm trying to wrap my head around closures in Javascript.
Here is an example from a tutorial:
function greeter(name, age) {
var message = name + ", who is " + age + " years old, says hi!";
return function greet() {
console.log(message);
};
}
// Generate the closure
var bobGreeter = greeter("Bob", 47);
// Use the closure
bobGreeter();
The author said that this is an effective way of using closure to make private variables, but I don't get the point.
Could someone enlighten the benefits of coding like this?
A closure is a pair of a function and the environment in which it was defined (assuming lexical scoping, which JavaScript uses). Thus, a closure's function can access variables in its environment; if no other function has access to that environment, then all of the variables in it are effectively private and only accessible through the closure's function.
The example you provided demonstrates this reasonably well. I've added inline comments to explain the environments.
// Outside, we begin in the global environment.
function greeter(name, age) {
// When greeter is *invoked* and we're running the code here, a new
// environment is created. Within this environment, the function's arguments
// are bound to the variables `name' and `age'.
// Within this environment, another new variable called `message' is created.
var message = name + ", who is " + age + " years old, says hi!";
// Within the same environment (the one we're currently executing in), a
// function is defined, which creates a new closure that references this
// environment. Thus, this function can access the variables `message', `name',
// and `age' within this environment, as well as all variables within any
// parent environments (which is just the global environment in this example).
return function greet() { console.log(message); };
}
When var bobGreeter = greeter("Bob", 47); is run, a new closure is created; that is, you've now got a new function instance along with the environment in which it was created. Therefore, your new function has a reference to the `message' variable within said environment, although no one else does.
Extra reading: SICP Ch 3.2. Although it focuses on Scheme, the ideas are the same. If you understand this chapter well, you'll have a good foundation of how environments and lexical scoping work.
Mozilla also has a page dedicated to explaining closures.
The purpose of a closure is so that the variables you use inside a given function are guaranteed to be "closed" which means they do not depend on external variables - they only depend on and use their arguments. This makes your Javascript methods closer to a pure function, that is, one that returns the same value for the same given arguments.
Without using closures, your functions will be like Swiss cheese, they will have holes in them. A closure plugs up those holes so the method doesn't depend on variables higher in the scope chain.
Now, up until this point, my answer has been simply about organizing your code and style. So take this simple example. At the line with the comment, I invoke a function and the value of the variable a is captured for future use.
var a = "before";
var f = function(value) {
return function()
{
alert(value);
}
} (a); //here I am creating a closure, which makes my inner function no longer depend on this global variable
a = "after";
f(); //prints "before"
Now, why would you need to do this? Well, here's a practical example. Consider the following code that uses jQuery to add 5 links to the document. When you click a link, you would expect it to alert the number associated with the link, so clicking the first you would think would alert 0, and so on. But, this is not the case, each link will alert the value of 5. This is because the function I define depends on the variable i which is being modified outside the context of the function. The function I pass into bind is a Swiss cheese function.
for (var i = 0; i < 5; i++)
{
var a = $('<a>test link</a>').bind('click', function(){
alert(i);
});
$(a).appendTo('body');
}
Now, let's fix this by creating a closure so each link will alert its correct number.
for (var i = 0; i < 5; i++)
{
var fn = function (value) {
return function() {
alert(value);
};
} (i); //boom, closure
var a = $('<a>test link</a>').bind('click', fn);
$(a).appendTo('body');
}
I don't think this is a good example for private variables, because there are no real variables. The closure part is that the function greet can see message (which is not visible to the outside, hence private), but it (or anyone else) is not changing it, so it is more of a constant.
How about the following example instead?
function make_counter(){
var i =0;
return function(){
return ++i;
}
}
var a = make_counter();
console.log(a()); // 1
console.log(a()); // 2
var b = make_counter();
console.log(b()); // 1
console.log(a()); // 3
A better example may be
function add(start, increment) {
return function() {
return start += increment;
}
}
var add1 = add(10, 1);
alert(add1()); // 11
alert(add1()); // 12
Here, every time you call the returned function, you add 1. The internals are encapsulated.
The returned function still has access to its parents variables (in this case, start and increment).
On a lower level of thinking, I think it means that the function's stack is not destroyed when it returns.
Once you "get it" you will wonder why it took you so long to understand it. That's the way way I felt anyways.
I think function scope in Javascript can be expressed fairly concisely.
The function body will have access to any variables that were visible in the lexical environment of the function declaration, and also any variables created via the function's invocation -- that is, any variables declared locally, passed through as arguments or otherwise provided by the language (such as this or arguments).
It's called "closures" because they are "closed" around free variables, and there are much more ways to use it then only hiding state. For example, in functional programming, where closures came from, they are often used to reduce parameters number or set some constant for a function. Let's say you need function goodEnough() that will test if some result is better then some threshold. You can use function of 2 variables - result and threshold. But you can also "enclose" your constant inside function:
function makeThresholdFunction(threshold) {
return function(param) {
return (param > threshold);
}
}
var goodEnough = makeThresholdFunction(0.5);
...
if (goodEnough(calculatedPrecision)) {
...
}
With closures you can also use all the tricks with functions such as their composition:
function compose(f1, f2) {
return function(arg) {
return f1(f2(arg));
}
}
var squareIncremented = compose(square, inc);
squareIncremented(5); // 36
More on closure design and usage can be found at SICP.
I found this a pretty helpful article.
When is a function not a function?
//Lets start with a basic Javascript snippet
function generateCash() {
var denomination = [];
for (var i = 10; i < 40; i += 10) {
denomination.push(i);
}
return denomination;
}
This a basic function statement in Javascript that returns an array of [10,20,30]
//--Lets go a step further
function generateCash() {
var denomination = [];
for (var i = 10; i < 40; i += 10) {
denomination.push(console.log(i));
}
return denomination;
}
This will print 10, 20 ,30 sequentialy as the loop iterates, but will return an array of [undefined, undefined, undefined], the major reason being we are not pushing the actual value of i, we are just printing it out, hence on every iteration the javascript engine will set it to undefined.
//--Lets dive into closures
function generateCash() {
var denomination = [];
for (var i = 10; i < 40; i += 10) {
denomination.push(function() {
console.log(i)
});
}
return denomination;
}
var dn = generateCash();
console.log(dn[0]());
console.log(dn[1]());
console.log(dn[2]());
This is a little tricky, what do you expect the output will be, will it be [10,20,30]? The answers is no, Lets see how this happens. First a Global execution context is created when we create dn, also we have the generatecash() function. Now we see that as the for loop iterates, it creates three anonymous function objects, it might be tempting to think that the console.log within the push function is getting fired too, but in reality it is not. We haved invoked generateCash(), so the push function is just creating three anonymous function objects, it does not trigger the function. At the end of the iteration, the current local context is popped from the execution stack and it leaves the state of i : 40 and arr:[functionobj0(), functionob1(), functionobj2()].
So when we start executing the last three statements, all of them output 40, since it is not able to get the value of i from the current scope, it goes up the scope chain and finds that the value of i has been set to 40. The reason all of them will fire 40 is beacause every single component of dn lies in the same execution context and all of them on being not able to find the value of i in their current scope will go up the scope chain and find i set as 40 and output it respectively