Hi, Brendan, thank you for reply.
I mean in common understanding, "a>=b" always have the same result with " a>b || a==b ". But I noticed that in ES5/ES3, there are several cases breaking this rule. See the following: null == 0 // false null > 0 // false null >= 0 // true I was wondering if this is by design. And, is it possible to have some change in future versions of ES? 2012/9/25 Brendan Eich <[email protected]> > Frank Quan wrote: > >> null == 0 // false >> null > 0 // false >> null < 0 // false >> >> null >= 0 // true >> null <= 0 // true >> >> The above expressions are weird compared to the all-false "undefined". >> Why doesn't the spec treat null like undefined? >> > > This is not really a question whose answer can change (not by default, > anyway). Perhaps some day with opt-in metaprogramming of operators within a > lexical scope. > > The spec was not made up first, then implemented. The first > implementation, by me in Netscape 2 in 1995 done in 10 days, included > user-testing on some developers who really wanted something broken for ==, > and I foolishly gave it to them (and to everyone). > > The difference you see above is not specifically due to null vs. > undefined, rather to == vs. the relational operators. Relationals convert > to Number (the spec's term for the IEEE double type reported by typeof as > "number"), and null converts to 0: > > js> +null > 0 > > The broken Equality operators == and != are more complicated, but in this > case they at least do not convert null at all, rather they notice that its > type is Null (ECMA spec term) and not the same as the right-hand side, > which is Number, and so (based on both types not being caught by earlier > steps in 11.9.3) the result for == is always false, != always true. > > The non-conversion of null in this case is actually good. Doesn't make up > for all the broken-ness, though. > > /be >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
