Number.isNaN

John-David Dalton john.david.dalton at gmail.com
Fri Dec 14 12:49:35 PST 2012


I apologize for the duplicate post, but I think my reply got lost in its
formatting.

The Modernizr example was in response to Axel's request for an example of
boxed values being used in real world projects.

Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods or equivalents that treat boxed and unboxed values as like:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`

`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed the same in their
`isXyz` I think it's natural for the spec to follow in the case of
`Number.isNaN`.

Thanks,
-JDD


On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Domenic Denicola wrote:
>
>> From: es-discuss-bounces at mozilla.org [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 :( :( :(
>>
>
> Restricted productions creating new operators may be at risk (Allen's
> right, we haven't had an orderly decision in TC39 on this point), but
> Object.is or Object.isSameValue is definitely not dead.
>
> Allen's right too that we have some disagreement on the use of SameValue
> under the hood in Map and Set.
>
> /be
>
>
>> (Someone want to find a link to the minutes that killed it? I keep having
>> to correct people on this.)
>>
>>  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
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121214/ab9d4ae2/attachment.html>


More information about the es-discuss mailing list