Re[2]: Language design

KOLANICH kolan_n at mail.ru
Sat Jun 13 00:21:39 UTC 2015


 >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 <brendan at 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 at mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150613/66b99554/attachment.html>


More information about the es-discuss mailing list