On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton <[email protected]> wrote: > Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It > would still prevent the global `isNaN('foo')` confusion. Though > `Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just > an oversight?
No. Object.is correctly reports that these are different. > I know `Object(NaN)` is totally edge case but it still has the > brand of BultinNumberWrapper and is NaN (boxed). > > > > On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban <[email protected]> wrote: >> >> >> From: Mark S. Miller [mailto:[email protected]] >> >> >> >> In that case, the current spec is wrong. The purpose of introducing >> >> Number.isNaN is to repair the >> following bug in the global isNaN: >> >> >> >> isNaN("foo") // returns true >> >> Indeed, as Yusuke noted on the other reply, I referred to the wrong >> 'isNaN'. And as you note, the point of the 'Number.isNaN' variant is to >> avoid any coercions. >> >> That still leave's JDD's original suggestion to allow >> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive >> or boxed Number. It feels a little odd to introduce another kind of limited >> coercion into the language, but perhaps it is practically valuable to not >> differentiate boxed and unboxed numbers here? >> >> Luke >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
