Front end to Zhaohun: The value of the statement in JavaScript

Folder

• Folder
• The question is, is the statement a value?
• So you lied to me, huh?
• What's the use of rice?
• To study whether this is a pain in the idle.
• ES5ES6, what's the difference?
• The conclusion is that ES6 is changing the rules, but more reasonable.
• Last but not the IF statement

In the third edition of the book, which was written in the essence of the language, the two days discussed the difference between ES6 and ES5 on the value of the statement. Just Weibo also have classmates to this question is interested, so specially organized this article.

Writing a blog can be a bit verbose, writing a book is not. So this article is different from what you can see in the book.

The question is: Does the statement have a value?

Very unfortunate. What we are faced with is indeed a language with a value in a statement. In JavaScript. The code is interpreted as a statement line (Statement Lists), so eval () is essentially a statement line that runs. Like what:

eval("1+2+3")

The expression is not actually evaluated, but rather is interpreted as running "code text". Because a block of text implicitly has a "text/file Terminator (EOF)", it is equivalent to the line terminator (EOL) of the statement delimiter for JavaScript. So the above code is equivalent to:

eval("1+2+3;")

If you don't want to know the specifics, then remember that "JavaScript runs on a statement line".

So...... What exactly is the value of this statement? Unfortunately, in the demo example above, the value of the statement is the same as the expression value, which is also 6.

So, you lied to me, huh?

You see, JavaScript has a type of statement, called an expression statement. Unfortunately, most of the statements you see are expression statements. Like what

Object.toString()

Here is a method call (an expression). You add a semicolon (;) in the back, and in the syntax it becomes a statement line, so it becomes an expression statement. Because JavaScript also has a single-value expression, a single value can be a statement.

This is actually the reason that the function or block first puts the "use strict" in a little bit of a vainly disobey-it is consistent with JavaScript's traditional grammatical conventions:

function foo() {  "use strict";  1;  true;}

The code above is legal, and the function foo () has three single-value statements in it. The function declaration itself is also a statement. The function declaration (and all explicit declaration statements) is not a return value-it is defined in ECMAScript to return empty.

The return value of a function call is determined by the call operator "()". This operator requires return for a value, assuming none is considered undefined. This is the source of some of the features of the JavaScript function.

"Expression operations" and "statement-valued" can explain many of the puzzles in JavaScript's grammatical features, which are some of the basic properties of the language in design.

What's the use of rice?

Since Eval () is essentially a running statement rather than an expression, how the statement returns the value becomes the function's last attribute. It is important to note that not eval () is evaluated, but that the JavaScript code block/statement line itself has values, and eval () returns this value only. Assume that there is no such feature. Ajax can not be done, because we often use AJAX/JSONP from the far end to take a value, that is, eval () "Parse", here is the "run statement and take value" feature.

In JavaScript, the statement has a value, and the value of the statement block (compound statement) is the value of the last value statement in the block. According to the original text of ECMAScript is:

The value of a statementlist is the value of the last value producing item in th E statementlist. For example, the following calls to the Eval function all return the value 1:

The production ifstatement:if (E Xpression) Statement Else Statement is evaluated as follows:

1. let Exprref be the result of evaluating Ex Pression.
2. If ToBoolean (GetValue (Exprref)) is true, then
   A. Return The result of evaluating the first Statement.
3. Else,

eval  ( "1;;;;;" ) eval  ( "1;
{} ") eval  (" 1;var A; ")  

The term "value producing item" is called "value producing Statement" in ES5. However, I did not find a clear statement in the ES5/ES6: Which statements are the statements that generate values?

Do you think it's a pain to study this?

It doesn't hurt to have anything to do with this yarn.

The study of this is actually a very important thing, because the following line of code exactly how to explain, depends on our research here:

// sourceText at remoteif (x) (  function aa() {})else (  function bb() {})

We assume that the code snippet above is from the far end. Then we get it in the way of Ajax. Called "SourceText", what is the result of the following code?

trueeval(sourceText);console.log(foo.name);  // "name" property define in ES6

First explain the Aa/bb function. Note that the two functions here are syntactically not "function declaration statements", but "function expressions"--note that "()" is used here to force them to be an expression.

That's not what I'm talking about, it's classified in the official documents of the MDN (Mozilla Developer Network). "Function statement" and "function expression" are two different things.

"Function declaration statement" is not a value. The function expression is a value, and the "function expression statement" is the value. So the sourcetext. Suppose X is true. The IF statement should return the value of AA, otherwise the value of BB will be returned. So. In the Demo sample code:

eval(sourceText);

is meaningful, and finally the console will output "AA". Indicates that the Foo function is from an AA () function expression. Now it seems that the following sentence is really practical:

The value of the IF statement. Is the value of the last Statementlist value statement in its Then/else branch.

What difference does Es5/es6 have?

The two days when I wrote the book found a bit different from the previous understanding of the place (I used the Nodejs in the old version of the V8). So it is not clear ECMAScript definition of the problem, or V8 implementation of the problem.

So he grabbed the hax to discuss. But the guy ignored me--so I decided to go to Shanghai for him this week. Let's talk about this later.

What's the difference?

The problem is said in the ES5. Assuming that there are no statements in the Then/else branch, that is, Statementlist is empty, then the IF statement results are null. His definition is very easy, it's written like this:

The production ifstatement:

? if (Expression) Statement else Statement

is evaluated as follows:

1. Let Exprref is the result of evaluating Expression.

2. If ToBoolean (GetValue (Exprref)) is true and then
   A. Return the result of evaluating the first Statement.

3. Else,
   A. Return the result of evaluating the second Statement.

Assume that "first Statement" is emptystatement. The result, of course, is empty. For Empty,javascript, this "statement value" is ignored.

This means that:

1;{};;

Of the above three statements, lines 2nd and 32 are actually empty statements-their values are empty. is ignored. So the entire code text will return 1.

So follow this rule. The following code:

1if (true);// 或1if (false);

Both of these should return 1. This is the case in the ES5.

In ES6, however, this specification is written as follows:

4~5:let stmtcompletion Be the result of First/second Statement
6:returnifabrupt (stmtcompletion).

7:if stmtcompletion. [[value]] is not empty, return stmtcompletion.

8:return normalcompletion (undefined).

This means: Suppose that the result of Then/else is not empty then return them, otherwise. You have to return to "undefined".

So here's a demo example:

1if (true);

It's time to return to the undefined.

Of course I read the ES6 in the morning, and my problem was. I used the old version of V8 in Nodejs, as well as the old versions of Firefox/chrome, to test-they declared that they supported ES6. However, in this feature, the ES5 is still the same way.

So I 懞: the engines that claim to support ES6 are wrong. Or is the standard not written right?

It is precisely because the understanding of the standard more than the understanding of the Hax not appear as expected. So I always thought

"Standards are written by people. It's people who write and they get it wrong.

I chose to believe ... The same is also a bunch of people (and also the same bunch of people) write ES5.

Assuming ES5 is right, then ES6 is wrong.

The conclusion is that ES6 is changing the rules, but more reasonable

The way to verify this is that the new V8 engine in Chrome and the new version number for Firefox are all using the specifications in ES6. Of course, it's very unfortunate that you're supposed to test it with Nodejs. At least the current version number (4.4.2/5.10.1) is still wrong and is implemented in accordance with the ES5 specification.

So why do I finally feel that ES6 is "more reasonable"?

Still have to go back to the "statement should not have value" the fundamental issue to discuss.

First, ECMAScript is the acknowledgment that the statement has value, and at the same time admits that "some statements do not have values/No values". For example, an empty statement does not produce a value, a function declaration, a variable declaration, and so on.

-For batches of statements, no value is generated in the context of the code, and the resulting value affects the result. So it is important to understand "which has value, which has no value". In ES5, this problem leads to uncertainty about the outcome of the IF statement.

Since:

Assuming that the statement in Then/else has a value, the if has a value. If no value is assumed, then if there is no value.

The following code, then, is an indeterminate semantics:

// sourceText at remote"hello";if (x) (  function aa() {})

When x is true, the IF statement has meaning. When x is false, the IF statement is meaningless in context-it has no effect on the resulting value. and

There is uncertainty about the effect of the "ES5" if statement on the result value

This result is a very failure in semantic design.

And in the ES6:

The "ES6" if statement always has a result value, either a result of then/else, or a undefined

This makes the if has a definite semantics.

At last. No, but if statement

It is not idleness to write the ECMAScript 262 (except when writing 4th), some people really want to know. For example, the question of the value of this statement is not fundamentally "what happens if statement", but rather "how to deal with the value of a statement".

My basic job last night was to sort out all these statements. The effect of the values, if/for/while/try and so on, and so on the value of the processing of the amazing consistency. In addition to these statements and expression statements, Return/yield/throw is the only way to explicitly return the result.

So. The behavior of the statement above the "generating value producing" is unified in ES6.

Front end to Zhaohun: The value of the statement in JavaScript