What is the "closure" of JavaScript (2)

My last blog title was wrong, causing some misunderstanding. I think the purpose of the blog is not to recite textbooks, but to share research and development experience. My last title was changed to "an issue withJavaScript closures: Its impact on outer scope ", because I did not strictly analyze the definition of closures, but rather analyzed one of the semantic aspects of implementing closures.

It's a hassle to be clear about closures, and I don't see any definitive writings on JavaScript (like C + + programming that have Bjarne Stroustrup in the C + + language language ). so in addition to studying JavaScript language standardECMA-262 specification, I can't recommend a discussion about "closures" of the best textbooks.

The "Scope chaining" of the Netizen "Mu Yi" is indeed more close to the essence, but it is not comprehensive. I had to take a chance and try again.

The implications of closures include the following three main concepts:

Lexical Scope and Scope Chain

The concept of Lexical scope is not a javacript invention, but as part of the JavaScript function, it is an added value in the concept of "traditional" functions.

The lexical scope and runtime scope of the traditional functions (c, C + +, Java, C #, etc.) are the same. The lexical scope of JavaScript refers to the "environment" when the function is defined , not the environment in which the function is run.

For a particular function, its "free variable" is the main content that needs to be captured in this function closure. The lexical capture (capture) Order of free variables (variables not defined by this function ) is (that is, the order of scope chaining):

A, the local variable of the parent function

B. Input argument of the parent function

C Repeat A, B, in the parent function of the parent function, until the topmost level (GLOBAL scope)

In the definition of the following MYOBJ :

var x = 1000; //Line 0

function myObj(x, y) {// Line1

THIS.FUNC1 = function () {// Line2

x + +;

Y--;

}

This.get1 = function ()

{

return x;

}

This.get2 = function ()

{

return y;

}

var x = 0; Line 3

}

MYOBJ . prototype. AddTwo = function (z)

{

return This.get1 () + this.get2 () + Z;

}

var m1 = new myObj(10, 20); Line 4

var m2 = new myObj(30, 70); Line 5

Console.log (' m1.x: ' + m1.get1 ()); Line 6

Console.log (' m1.y: ' + M1.get2 ()); Line 7

Console.log (' m2.x: ' + m2.get1 ()); Line 8

Console.log (' m2.y: ' + M2.get2 ()); Line 9

For the above example, if it is not lexical scope, line 6 to line 9 prints should be 10, 20, 30, 70.

But because lexical scope captures the order, X is 0 ( See Line 3), so the print is: 0, 20, 0, 70.

Comment out the line3, according to the order of capture, the print is 10, 20, 30, 70.

change the myObj(x, y) to myObj(z, y), and the print is 1000, 20, 1000, 70. 1000 of them were captured from global (line 0).

Lexical capture was performed at the parsing stage.

The above capture order must be performed at the parsing stage of the function. In the data structure of the function, all the "reference" of the capture variable are already included in the parsing, and the run phase will not change. This is why the above Line 3 definition can take precedence over the input parameter x . If capture is executed, Line 3 is after the definition of the function, and the capture is said to be the input parameter x.

C,c++ and other compiled languages are translated directly into the native function, and all function information is dynamically obtained by stack frame. The only concept close to closures is the "full variable (global variable)". These global variables are also converted to memory addresses at compile time and can be "resolved in place" at runtime without a separate closure. These functions are not object and do not need to be generated dynamically, so there is no need for a "static" closure.

JavaScript needs a separate closure, I think because all JavaScript is object, can be "dynamically generated", but the definition (first parsing) is static, this "static" part needs closure, the dynamic part and the traditional function, Supported by the runtime context.

This "complexity of implementation" is the cost of the convenience of handling asynchronous events in order to bring about closures.

Lexical capture is reference not value

This is the place I want to emphasize in my last blog. If the above myobj executes, if the value of X is captured, then these three functions func1,get1,Get2 will not have any connection.

Because the capture is X's reference, so the above three functions see X is the same variable.

This is important because the local variables in JavaScript are not all in the heap . At least GOOGLE V2 is not. But the x above line 3 must be "Born and live" in the heap , otherwise func1,get1, Get2 will work on the destroyed stack variable x , making the above program meaningless.

In other words, the runtime cost of closures is to transfer the closed variables from the stack to the heap .

Summarize

I think that only by understanding the closure of the appeal of three concepts, can be in the closure of the application of an invincible position.

2014-8-26 in Seattle

What is the "closure" of JavaScript (2)