What is the "closure" of JavaScript? (2)

What is the "closure" of JavaScript? (2)
The title of my previous blog is incorrect, causing some misunderstandings. I think the purpose of a blog is not to back up textbooks, but to share the R & D experience. The title of my previous article should be changed to "an issue of JavaScript closure: its impact on outer scope" because I did not strictly analyze the closure definition, instead, it analyzes a semantic problem of implementing closures. Clearly speaking about closures is a headache, and I have not seen any authoritative JavaScript works (for example, C ++ programming language with Bjarne Stroustrup ). So in addition to reading the Standard ECMA-262 specification, the international Standard for JavaScript language, I cannot recommend the best teaching material about closures. The "scope chaining" of "Mu Ji" is indeed close to the essence, but it is not comprehensive. I had to make another attempt. The meanings of closures include the following three main concepts: Lexical Scope and Scope ChainLexical Scope is not invented by javacrept, but it is a part of JavaScript Functions, is an added value in the concept of "traditional" functions. The lexical scope and runtime scope of traditional functions (C, C ++, Java, C #, etc.) are the same. The lexical scope of JavaScript refers to the "Environment" when the function is defined, rather than the environment when the function is run. For a specific function, its "free variable" is the main content to be captured in this function closure. The lexical capture (capture) Order of free variables (variables not defined in this function) is (that is, the scope chaining order): A, the local variable B of the master function. the input argument C of the primary function. repeat A and B in the primary function of the primary function until the top-level (GLOBAL scope) is defined in 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) {r Eturn 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 ~ Line 9 should print 10, 20, 30, 70. However, because lexical scope captures the order, x is 0 (see line 3), so it is printed as follows: 0, 20, 0, 70. Comment out line3 and print 10, 20, 30, and 70 according to the capture order. Change myObj (x, y) To myObj (z, y), and the printed values are 1000, 20,100, 0, and 70. Among them, 1000 are captured from global (Line 0. Lexical capture is performed in the parsing stage. The above capture sequence must be performed in the parsing stage of the function. In the data structure of the function, after parsing, all "reference for capturing variables" is included, and the running phase will not change. This is why line 3 defined above takes precedence over input parameter x. If it is capture during execution, line 3 is after the function is defined, because it is the input parameter x. C, C ++ and other compilation languages are directly translated into native functions, and all function running information is dynamically obtained by stack frame. The only concept that is close to closure is "global variable )". these global variables are also converted into memory addresses during compilation, and can be "solved locally" during runtime without an independent closure. These functions are not objects and do not need to be dynamically generated. Therefore, they do not need a "static" closure. JavaScript requires an independent closure because all JavaScript is an object and can be "dynamically generated", but the definition (the first parsing) is static, the "static" part requires closure. The dynamic part is the same as the traditional function and is supported by the runtime context. This "implementation complexity" is for the convenience of closure and the cost of processing asynchronous events. Lexical capture is reference, not value. This is what I want to emphasize in my previous blog. If the value of x is captured during myObj execution, the three functions func1, get1, and get2 will not be associated. Because x's reference is captured, the preceding three functions see x as the same variable. This is important because not all local variables in JavaScript are in heap. At least GOOGLE V2 is not. However, line 3's x must be "born and live" in heap; otherwise, func1, get1, and get2 will work on the destroyed stack variable x, this makes the above program meaningless. That is to say, the runtime of the closure is to transfer the variable of the closure from the stack to heap.