In-depth understanding of JavaScript Scope Series second-lexical scope and dynamic scope

xTable of Contents [1] lexical [2] dynamic front words

Most of the time, the main reason we are confused about scopes is whether we should make variable lookups in terms of the nesting order of function locations or in the order in which functions are called. Coupled with this mechanism of interference, so that variable lookup is very error-prone. This is actually caused by the two scope work model, which is divided into lexical scope and dynamic scope, and distinguishes between these two scope models to have a clear understanding of the variable lookup process. This article is an in-depth understanding of the second chapter of the JavaScript scope series-lexical scope and dynamic scope

Lexical scopes

In the first article, the first working stage of the compiler is called participle, which is to break up a string of characters into lexical units. This concept is the basis for understanding lexical scopes

In short, the lexical scope is defined as the scope of the lexical phase, which is determined by where the variables and block scopes are written when the code is written, so that the scope remains the same when the lexical parser processes the code.

Relationship

Regardless of where the function is called, and no matter how it is called, its lexical scope is determined only by the position where the function is declared.

function Foo (a) {    var b = A * 2;     function Bar (c) {        Console.log (A, B, c);    }     * 3//  2 4

In this example, there are three scopes that are nested in a hierarchical set. To help understand it, you can think of them as a number of bubbles that are progressively contained.

Scope bubbles are determined by where their corresponding scope block codes are written, and they are included in a hierarchical

Bubble 1 contains the entire global scope, with only one identifier: foo

Bubble 2 contains the scope created by Foo, with three identifiers: A, bar, and B

Bubble 3 contains the scope created by bar, where there is only one identifier: C

Find

The structure of the scope bubbles and their relationship to each other gives the engine sufficient location information that the engine uses to find the identifier's location

In the code snippet, the engine executes the Console.log (...) Declaration and look for references to a, B, and c three variables. It starts with the most internal scope, i.e. bar (...). The scope of the function begins the lookup. The engine cannot find a here, so it goes to the top level to the nested foo (...). continues to be found in the scope of the A is found here, so the engine uses this reference. The same is true for B. For C, the engine is in bar (...). Found it in the

[note] The lexical scope lookup only looks for the first-level identifier, and if the code references Foo.bar.baz, the lexical scope lookup will only attempt to find the Foo identifier, and after the variable is found, the object property access rules take over access to bar and Baz properties, respectively

Foo = {    bar:{        1    }};console.log (foo.bar.baz); // 1

Covered

Scope lookups start at the most internal scope at run time, step outward or upward, until the first matching identifier is met

An identifier with the same name can be defined in a multi-layered nested scope, which is called a "masking effect", and the internal identifier "obscures" the external identifier

var a = 0; function Test () {    var a = 1;    Console.log (a); // 1 }test ();

　　Global variables are automatically properties of global objects, so they can be accessed indirectly by reference to global object properties, not directly through the lexical name of the global object.

var a = 0; function Test () {    var a = 1;    Console.log (WINDOW.A); // 0 }test ();

This technique provides access to global variables that are obscured by variables of the same name. But a non-global variable, if obscured, cannot be accessed in any way.

Dynamic scopes

JavaScript uses lexical scopes, and its most important feature is that its definition process takes place in the writing phase of the code.

So why do we introduce dynamic scopes? The dynamic scope is actually the cousin of the other important mechanism of JavaScript. The scope confusion is mostly due to the confusion of lexical scopes and this mechanism, which is not clear

Dynamic scopes do not care about how functions and scopes are declared and declared at any point, only about where they are called from. In other words, the scope chain is based on the call stack, not the scope nesting in the code

var a = 2; function foo () {    console.log (a); }function  Bar () {    var a = 3;    Foo ();} Bar ();

"1" If it is in the lexical scope, which is now the JavaScript environment. The variable A is first found in the Foo () function and is not located. It then finds and assigns a value of 2 along the scope chain to the global scope. So the console output 2

If the "2" is in a dynamic scope, similarly, the variable A is first found in Foo (). This will follow the call stack in the call to the Foo () function, the bar () function, find and assign a value of 3. So the console output 3

The difference between the two scopes, in short, lexical scopes are determined at the time of definition, while dynamic scopes are determined at run time

In-depth understanding of JavaScript Scope Series second-lexical scope and dynamic scope