allen at wirfs-brock.com
Fri Dec 14 11:02:13 PST 2012
On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote:
>> From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Nathan Wall [nathan.wall at live.com]
>> Sent: Friday, December 14, 2012 13:34
>> On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and `Object.is`. It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment.
> `is` operator is dead :( :( :(
> (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.)
I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds.
BTW, I think there are probably other related issues that need to be discussed/resolved at that level. For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available.
>> There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does.
> This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x => Object.is(x, NaN))`.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss