why (null <= 0) is true?
yuyuenjoy at gmail.com
Tue Sep 25 03:13:33 PDT 2012
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 <brendan at mozilla.com>
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss