Starting from null> = 0

Let's start with a set of use cases.Code:

 
Null> 0 // false null = 0 // false null> = 0 // true
 

The main content we are discussing today is not how strange this result may look. but why. I wrote a note here mainly because after some confirmation from Brendan eich. I found that the answer is different from my original guess. so I have some reflections, and I have some subjective understanding of Es.

 

Before starting, let's start with ES3 and es5 definitions:

Note 1: ES3, es5 pairs of Relational operators ">", "<", "> =", "<=", and equal operators are almost the same in key aspects, so we will not list es5 any more.

NOTE 2: For the following content, you only need to pay attention to the red part. Other parts are irrelevant. I will give a rough explanation of this content in the following sections.

NOTE 3: <= and <are similar to each other ..

 

ES3 ">" OPERATOR:

The greater-than operator (>)
The production relationalexpression: relationalexpression> shiftexpression is evaluated as follows:
1. Evaluate relationalexpression.
2. Call getvalue (Result (1 )).
3. Evaluate shiftexpression.
4. Call getvalue (result (3 )).
5.Perform the comparison result (4) <result (2 ).
6. If result (5) is undefined, return false. Otherwise, return result (5 ).

 

ES3 "> =" OPERATOR:

The greater-than-or-equal operator (> =)

The production relationalexpression: relationalexpression> = shiftexpression is evaluated as follows:
1. Evaluate relationalexpression.
2. Call getvalue (Result (1 )).
3. Evaluate shiftexpression.
4. Call getvalue (result (3 )).
5. Perform the comparison result (2) <result (4). (See 11.8.5 ).
6. If result (5) is true or undefined, return false. Otherwise, return true.

 

ES3 OPERATOR:

The equals operator (=)

The production equalityexpression: equalityexpression = relationalexpression is evaluated
Follows:
1. Evaluate equalityexpression.
2. Call getvalue (Result (1 )).
3. Evaluate relationalexpression.
4. Call getvalue (result (3 )).
5. Perform the comparison result (4) = result (2). (See 11.9.3 ).
6. Return result (5 ).

ES3AlgorithmImplementation:

The abstract relational comparison algorithm

The comparison X <Y, where X and Y are values, produces true, false, or undefined (which indicates that
At least one operand is Nan). Such a comparison is saved med as follows:
1. Call toprimitive (x, hint number ).
2. Call toprimitive (Y, hint number ).
3. If type (Result (1) is string and type (result (2) is string, go to Step 16. (Note that this step differs
From step 7 in the algorithm for the addition operator + in using and instead of or .)
4. Call tonumber (Result (1 )).
5. Call tonumber (result (2 )).
6. If result (4) is Nan, return undefined.
7. If result (5) is Nan, return undefined.
8. If result (4) and result (5) are the same number value, return false.
9. If result (4) is + 0 and result (5) is −0, return false.
10. If result (4) is −0 and result (5) is + 0, return false.
11. If result (4) is + ∞, return false.
12. If result (5) is + ∞, return true.
13. If result (5) is −∞, return false.

14. If result (4) is −∞, return true.
15. If the mathematical value of result (4) is less than the mathematical value of result (5)-note that
These mathematical values are both finite and not both zero-return true. Otherwise, return false.
16. If result (2) is a prefix of Result (1), return false. (A string value p is a prefix of string value Q if Q
Can be the result of concatenating P and some other string R. Note that any string is a prefix of itself,
Because R may be the empty string .)
17. If Result (1) is a prefix of result (2), return true.
18. Let k be the smallest nonnegative integer such that the character at position K within Result (1) is
Different from the character at position K within result (2). (There must be such a K, for neither string
Is a prefix of the other .)
19. Let M be the integer that is the code point value for the character at position K within Result (1 ).
20. Let n be the integer that is the code point value for the character at position K within result (2 ).
21. If M <n, return true. Otherwise, return false.

 

ES3 Algorithm Implementation for internal Equality operations:

The abstract priority ity comparison algorithm

The comparison X = Y, where X and Y are values, produces true or false. Such a comparison is
Saved med as follows:
1. If type (X) is different from type (Y), go to Step 14.
2. If type (X) is undefined, return true.
3. If type (X) is null, return true.
4. If type (X) is not number, go to Step 11.
5. If X is Nan, return false.
6. If y is Nan, return false.
7. If X is the same number value as Y, return true.
8. If X is + 0 and Y is −0, return true.
9. If X is −0 and Y is + 0, return true.
10. Return false.
11. If type (X) is string, then return true if X and Y are exactly the same sequence of characters (same
Length and same characters in corresponding positions). Otherwise, return false.
12. If type (X) is Boolean, return true if X and Y are both true or both false. Otherwise, return false.
13. Return true if x and y refer to the same object or if they refer to objects joined to each other (see
13.1.2). Otherwise, return false.
14. If X is null and Y is undefined, return true.
15. If X is undefined and Y is null, return true.

16. If type (X) is number and type (Y) is string, return the result of the comparison X = tonumber (y ).
17. If type (X) is string and type (Y) is number, return the result of the comparison tonumber (x) = y.
18. If type (X) is Boolean, return the result of the comparison tonumber (x) = y.
19. If type (Y) is Boolean, return the result of the comparison X = tonumber (y ).
20. If type (X) is either string or number and type (Y) is object, return the result of the comparison X = toprimitive (y ).
21. If type (X) is object and type (Y) is either string or number, return the result of the comparison toprimitive (x) = y.
22. Return false.

 

The above content should concern about the important part that I ignored during my previous reading:

1. Relational operators and equal operators are not in the same category.

2. Relational operators. In terms of design, it is always necessary to convert the element into a number. In Design, equality operators are not considered in this regard.

3. the most important thing is not to take the result of A> B, A = B for granted to establish a contact with a> = B. the correct relationship with the original design idea is that A> B and A> = B are a group. A = B and other equal operators are a group. for example, a = B,! = B,! = B.

So we look at this problem in turn.

 
Null> 0 // if you try to convert null to number, the value is 0. so the result is false, null> = 0 // if you try to convert null to number, the value is 0 and the result is true. null = 0 // null is designed, and no transformation is attempted here. the result is false.
 

 

 

I personally did not realize these problems in my previous reading. As a result, I am stupid to think that the result of> = is a design mistake. The reason is that I simply think:

5. Perform the comparison result (2) <result (4). (See 11.8.5 ).
6. If result (5) is true or undefined, return false. Otherwise, return true.

The A> = B operator simply removes the inverse of the result of a <B. I think this is another reason for a design mistake: undefined, which is carried out in the standard. you must have discovered this point. for the undefined design, the undefined> 0, undefined <0, undefined = 0 results are consistent with the design and logic. null is the omission.

With this idea Es-discuss wrote a letter in an ingentle tone. question. the surprise is that Brendan eich has been paying attention to this issue. and immediately replied. the tragedy is that when I read the reply repeatedly, I still did not fundamentally understand this problem. until this morning. I read ES3, 5 again. related chapters. then suddenly realized.

 

At this point, my reflection is over. I also want to thank be for his earnest and prompt reply. As a CTO, Ren ran is so concerned and actively participates.Technical CommunityIs really admirable.

 

Next is the time to vomit:

Although in the previous example, I caught the original design idea of Be. but from a global perspective. from Relational operators to equal operators, especially equal operators. it's really messy. be mentioned in his letter that he is helpless to the = status quo. he even used the term "stupid" to describe his original implementation (of course, he also mentioned that it was just to design JS and run QA test cases within 10 days ). even so, but he still indicates null = 0. The result is what he wants.

Well, here I feel powerless. I think the design of relational and equality operations in Javascript is as follows. apart from confusion, I can't think of any other words to describe them more appropriately. this can be proved by the existence of a large number of type checks and defensive code in the production environment code.

 

Another reason is the es specification itself. for example, A> = B is the inverse of the result of a <B. this is an ambiguous statement. let's look at a typical JS example.

Function case1 (a) {if (a = NULL ){....}} function case2 (a) {if (a = undefined ){...}} // The above two groups are completely equivalent. This is an ambiguous expression. // We never know whether the purpose of the code writer is to match both null and undefined or only one function case3 () {if (a = NULL | A = undefined ){...}} // case3 is the best expression. we clearly understand the intent of the code writer. // even if many may think this code is stupid. but I firmly believe that this is good code.
 

Therefore, coding and writing standards should be clearly stated. even if the expression is ambiguous, it will not cause ambiguity or doubt. this is a good standard. document, code. avoiding ambiguity and various chaotic rules is the most appropriate design principle for a language.

 

Finally, I have to mention that Andrea giammarchi expressed his support for my previous views after I sent the letter null> = 0, which is the same as my original views, the result of null> = 0 should be false. we recommend that you modify the result in the strict mode of es7. although it was also opposed by David bruant. okay, sorry for this wrong opinion of him and me...