>You missed that Object.is(-0, +0) (and with arguments transposed) is false,
>while -0 === +0.
No. I really think that -0 === +0 also should be false, because they are
different objects. So should be 0=="0". I don't think it will break a lot of
code, because I cannot mind a situation where such comparisons can be needed
(except comparing zIndex and other numeric attributes casted to strings
automatically, but it is not very hard to insert parseFloat there).
>If your point is that Object.is does not pull its weight
My point is that there shouldn't not be a lot of similar API which behavior is
not intuitively clear.
I don't know what you think about it, but I think that this should have
semantics of comparison by value. We can compare numbers, so let 3.0==3 be
true. A string and a number have different semantics (string is array of
characters, number is number), so let 3=="3" be false.
Also ({a:1}=={a:1}) should be true; undefined==undefined should be true;
null==null should be true;NaN== NaN should be false;
Number.POSITIVE_INVINITY==Number.POSITIVE_INVINITY should be false.
=== has identity semantics
undefined===undefined shoulld be true; null===null should be true;NaN=== NaN
should be true; Number.POSITIVE_INVINITY===Number.POSITIVE_INVINITY should be
true because they all in fact a special value.
-0==+0 should be true, because it is the same number. -0===+0 should be false
because they are different values (which in case of integer can be understood
as differrent objects of class Number).
And again, I don't think that someone strongly relies on current semantics of
comparison because of its counterintuitivity.
Behaving the described way we only need the two operators.
Пятница, 12 июня 2015, 16:45 -07:00 от Brendan Eich <[email protected]>:
>Edwin Reynoso wrote:
>> Yes please edit it, you don't have to repost. BTW the only thing I can
>> agree with is the `Object.is()` which to me seems like the only
>> problem it solves is `Object.is(NaN, NaN)` now returns true
>
>You didn't agree with the root post (whose sender has had the "mod" flag
>set for moderated postings, btw). That root post ignored compatibility
>constraints that have been discussed to death over the years, and just
>glibly asserted that == and === could be changed. So, I don't believe
>you agreed with that noise. Am I mistaken?
>
>If your point is that Object.is does not pull its weight, make a
>stronger case for why people should have to write it by hand.
>
>You missed that Object.is(-0, +0) (and with arguments transposed) is
>false, while -0 === +0.
>
>/be
>_______________________________________________
>es-discuss mailing list
>[email protected]
>https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
