>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 <bren...@mozilla.org>: >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 >es-discuss@mozilla.org >https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss