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.
/be
-JDD
On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall <nathan.w...@live.com
<mailto:nathan.w...@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.
Nathan
_______________________________________________
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
