brendan at mozilla.com
Fri Dec 14 10:21:10 PST 2012
John-David Dalton wrote:
> > But `myNaN === myNaN` is true if `myNaN = Object(NaN)`.
> That's my point. Normally testing for NaN can be done via `myNaN !==
> myNaN` but `Object(NaN)` throws a wrench in that.
> It would be great if there was 1 function that was able to detect NaN,
> instead of having libs step up and do it.
Why? Who wraps NaN? Your modernizr true-wrapping Boolean example is both
a WTFJS moment, easily avoided by using a truthy object as Sam pointed
out, and nothing to do with NaN.
> On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall <nathan.wall at live.com
> <mailto:nathan.wall at live.com>> wrote:
> > Wat? This seems to be a good reason to allow `Object(NaN)` and
> use the
> > NumberWrapper brand as it cannot be tested via the normal way of
> > `myNaN !== myNaN`.
> But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing
> against the object is different. Nothing breaks.
> var myNaN = Object(NaN);
> [ 1, 3, myNaN ].indexOf(myNaN); // => 2
> Works as expected. The only problem which occurs is when you're
> working with primitive NaN, in which case the only existing good
> ways to test for it are `x !== x` and `typeof x == 'number' &&
> isNaN(x)`. The purpose of `Number.isNaN` is to provide a way to
> test this case which is easier to read and understand. Note that
> if `x = Object(NaN)` both of these tests fail.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss