Scope & Closures Chapter 2

YDKJSY Scope & Closures

Chapter 2 : Lexical Scope

Click to view full text

JavaScript is the only language that I'm aware of that people feel they don't need to learn before they start using it.- Douglas Crockford

Lex-time

JavaScript uses lexical scoping.

Lexing is the same as tokenizing: refer to chapter 1.

Lexical scope is based on where variables and blocks of scope are authored, by you, at write time.

consider this code:

function foo(a) {

  var b = a * 2;

  function bar(c) {
    console.log( a, b, c );
  }

  bar(b * 3);
}

foo( 2 ); // 2 4 12

There are three nested scopes in this code example.

The global scope, and has just one identifier in it: foo.
The scope of foo, which includes the three identifiers: a, bar and b.
The scope of bar, and it includes just one identifier: c.

The scopes are defined by where the blocks of code are written, which one is nested inside the other, etc.

Look-ups

The structure and relative placement of these scopes fully explains to the Engine all the places it needs to look to find an identifier.

Scope look-up stops once it finds the first match.

The same identifier name can be specified at multiple layers of nested scope, which is called "shadowing" (the inner identifier "shadows" the outer identifier). Regardless of shadowing, scope look-up always starts at the innermost scope being executed at the time, and works its way outward/upward until the first match, and stops.

No matter where a function is invoked from, or even how it is invoked, its lexical scope is only defined by where the function was declared.

Cheating Lexical

cheating lexical scope leads to poorer performance.

There are two mechanisms to cheat lexical scope.

The eval() function. Don't use it!
and with. Depricated.

There are other facilities in JavaScript which amount to a very similar effect to eval(..). setTimeout(..) and setInterval(..) can take a string for their respective first argument, the contents of which are evaluated as the code of a dynamically-generated function. This is old, legacy behavior and long-since deprecated. Don't do it!

The new Function(..) function constructor similarly takes a string of code in its last argument to turn into a dynamically-generated function (the first argument(s), if any, are the named parameters for the new function. This function-constructor syntax is slightly safer than eval(..), but it should still be avoided in your code.

Performance

Both eval(..) and with cheat the otherwise author-time defined lexical scope by modifying or creating new lexical scope at runtime.

The downside to these mechanisms is that it defeats the Engine's ability to perform compile-time optimizations regarding scope look-up, because the Engine has to assume pessimistically that such optimizations will be invalid. Code will run slower as a result of using either feature. Don't use them.

YDKJSY Scope & Closures Chapter 2 Lexical Scope