A Brief Talk and Guide on Active Objects (AO) in JavaScript

At present, there are many articles on the market, and in the era of ES202+, the original text of ES3 is still being copied.

Every execution context has associated with it a variable object. Variables and functions declared in the source text are added as properties of the variable object. For function code, parameters are added as properties of the variable object.

Then tie it to the "interviewer". In fact, there is no problem in using the concept of active objects in written understanding, but copying the original text without specifying the source will make people mistakenly believe that the concept of active objects is also defined in today's norms. In fact, the above quotation contains the content of the active object (Activation Object, AO, sometimes also called the active object, activation object) and the variable object (Variable Object, VO, sometimes also called the variable object), which are excerpted from two parts of ECMAScript 3 Spec And assemble it.

Today, here is a taste of active objects in JavaScript with everyone.

ECMAScript 1 / 3

In ECMAScript 1 and ECMAScript 3, there is indeed a definition of active objects.

When control enters the execution context of the function code, an active object is created and associated with the execution context, and the object is initialized with an attribute arguments with a characteristic of { DontDelete } The initial value of this attribute is a parameter object which will be described later.

Next, this active object will be used as a variable object for variable initialization.

The active object is purely a normative mechanism, and it is impossible to access it in ECMAScript. Only its members can be accessed, not the active object itself. When the call operator is applied to a reference value whose base object is the active object, the value of this for null .

——ECMAScript Language Specification 262 Edition 3 Final, 10.1.6 Active Object

But it is also limited to ECMAScript 1 and 3. Most of the articles about Active Objects and Variable Objects (Variable Object) that we get on the Internet (especially in the Chinese search environment) are ECMAScript 1 and 3 described for us, which are outdated.

If you are still interested in this content (in fact, I also suggest that you are interested), you can refer to:

• ECMA-262-3 in detail. Chapter 2. Variable object.：http://dmitrysoshnikov.com/ecmascript/chapter-2-variable-object/
• ECMA-262-3 in-depth analysis·Chapter 2·Variable objects (translation of the previous article): https://www.cnblogs.com/justinw/archive/2010/04/23/1718733.html

ECMAScript 5+

In ES5 and later versions of ES, the concept of active objects (AO) and a series of surrounding content no longer exists. Instead, there is a definition called Lexical Environments.

In other words, rigorously speaking, modern ECMAScript no longer has the concept of active objects, so when the content of "interviewer talks to you about AO" in articles on the Internet appears, it is actually "a big copy of market articles." Manifestation. They will also list the original text of the ECMAScript Spec for you (refer to the excerpt at the beginning of the article).

Regarding the lexical environment, you can refer to:

• ECMA-262-5 in detail. Chapter 3.2. Lexical environments: ECMAScript implementation.：http://dmitrysoshnikov.com/ecmascript/es5-chapter-3-2-lexical-environments-ecmascript-implementation/
• ECMA-262-5 Lexical environment: ECMA implementation (translation of the previous article): https://blog.csdn.net/szengtal/article/details/78726143

I won't go into details here.

Broadly active object

After the above two sections, we can know that the active object is the content in ECMAScript 1 / 3. In subsequent versions, it no longer exists. But can't the concept of active objects be brought up anymore?

Actually not, its corresponding concept can still be continued. It's just that people shouldn't be mistaken to think that there is a definition in modern ECMAScript. When we talk about active objects now, we should know that it is only a broad abstraction, not a narrow definition anymore. The generalized active object can also have different names in different scenarios, such as activation record (Activation Record), stack frame (Stack Frame), etc.

Whenever the function is called, it will create an active object. The object is invisible to the developer. It is a hidden data structure that contains some necessary information and bindings when the function is executed, as well as the address of the return value, and so on.

In C language, this object will be allocated and generated on a stack. When the function returns, the object will be destroyed (or popped).

You see, the "active object" here has been extended to the C language. It refers to an abstract existence, meaning Stack Frame.

JavaScript is different from the C language in that it allocates the object from the heap. And this active object will not be automatically destroyed when the function returns. Its life cycle is similar to the garbage collection mechanism of ordinary objects, which is determined based on the number of references.

An active object contains:

• Reference to the corresponding function object;
• The active object corresponding to the caller is used for the transfer of control right after return
• After the call is completed, the recovery information used to continue the execution of the subsequent logic, which is usually the address of an instruction that will be executed immediately after the function call is completed;
• The formal parameters corresponding to the function are initialized from the actual parameters;
• The variables in the undefined are initialized with 060a334c5dd6f0;
• Functions are used to calculate temporary variables of complex expressions;
• this , if the function is called as a method, then this is usually its host object.

In fact, the generalized "active object" after ES5+ is an extension of the active object defined by ES 1/3 and applied to the lexical environment.

So far, the analysis of "active objects" is enough. In the current environment, it's not that we can no longer talk about "active objects", but we can't talk nonsense, and we can talk with noses and eyes. Today's "active object" is a generalized abstract concept similar to active records and stack frames.

Otherwise, if you still use old articles to answer the so-called "interviewer" questions, it is likely to be brushed off.

Closure

Closures are also a clichéd concept. Why do you mention such a seemingly inconsistent concept in this article?

There has never been a very rigorous definition of closures. Such as:

Closures are functions that can read the internal variables of other functions.

Closures are functions that can read outer function variables.

Etc., etc.

Another example:

The sum of "function" and "variables accessible within the function" (also called environment) is a closure.

The above explanations are also extracted from various articles on the Internet. In fact, it is easy to understand, but the language description is not so rigorous. Everyone knows that's going on.

However, after we have a generalized active object, we can define closures from another perspective. how to say? Functions can be nested. When a nested function object is created, it will contain a reference to the active object corresponding to the outer function object

With this relationship, the closure is easily defined:

A function object that has a reference to the active object corresponding to the outer function object is called a closure.

Concise and concise. Although it is not as close to the people as "can read the variables in the outer function", it is also very simple. At the same time, with the "active object" as the main premise, I have helped to define a lot of preconditions, so this definition can also achieve the intended effect.

You can try to explain from this perspective what is a closure from the interview in the future. The premise is that you really understand and don't be entangled by the interviewer again.