Re: Number.isNaN

2012-12-18 Thread Olov Lassus
2012/12/14 Allen Wirfs-Brock al...@wirfs-brock.com 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

Re: Number.isNaN

2012-12-18 Thread gaz Heyes
On 14 December 2012 16:39, Allen Wirfs-Brock al...@wirfs-brock.com wrote: No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. The definitiveness of the test would be lost if other values such a

Re: Number.isNaN

2012-12-18 Thread David Bruant
Le 18/12/2012 14:43, gaz Heyes a écrit : On 14 December 2012 16:39, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way

Re: Number.isNaN

2012-12-14 Thread Sam Tobin-Hochstadt
On Fri, Dec 14, 2012 at 2:43 AM, Andreas Rossberg rossb...@google.com wrote: On 14 December 2012 06:46, John-David Dalton john.david.dal...@gmail.com wrote: Axel Rauschmayer: Honest question: I have yet to see boxed values in practice. Are there any real use cases? See Modernizr:

Re: Number.isNaN

2012-12-14 Thread Allen Wirfs-Brock
No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. The definitiveness of the test would be lost if other values such a Number wrapper instance also returned true when passed as the argument for

Re: Number.isNaN

2012-12-14 Thread John-David Dalton
No, the whole point of Number.isNaN is to provide a definitively test for NaN number values which cannot be tested for in the usual way using ===. 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

RE: Number.isNaN

2012-12-14 Thread Nathan Wall
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 =

Re: Number.isNaN

2012-12-14 Thread John-David Dalton
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. -JDD

Re: Number.isNaN

2012-12-14 Thread Mark S. Miller
EcmaScript koan: NaN is NotANumber. NaN is a number. Object(NaN) is not a number. Thus, Object(NaN) isn't NotANumber. On Fri, Dec 14, 2012 at 9:22 AM, John-David Dalton john.david.dal...@gmail.com wrote: But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. That's my point. Normally

Re: Number.isNaN

2012-12-14 Thread Brandon Benvie
That is deep. On Friday, December 14, 2012, Mark S. Miller wrote: EcmaScript koan: NaN is NotANumber. NaN is a number. Object(NaN) is not a number. Thus, Object(NaN) isn't NotANumber. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Number.isNaN

2012-12-14 Thread Brendan Eich
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

RE: Number.isNaN

2012-12-14 Thread Domenic Denicola
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@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

Re: Number.isNaN

2012-12-14 Thread John-David Dalton
Bendan Eich wrote: 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. The Modernizr example was in response to Axel's request for an example of boxed values being used in real world

RE: Number.isNaN

2012-12-14 Thread Nathan Wall
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

Re: Number.isNaN

2012-12-14 Thread Allen Wirfs-Brock
On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34 On another note, I do sort of wonder why `Number.isNaN` is coming into the

Re: Number.isNaN

2012-12-14 Thread Brandon Benvie
Speaking of SameValue, it's unnecessary in many/most of the places it's used in the spec. Like in IsEquivelentDescriptor the only comparison that needs to use SameValue is comparing the [[Value]] field. On Fri, Dec 14, 2012 at 2:02 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Dec 14,

Re: Number.isNaN

2012-12-14 Thread Brendan Eich
Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@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

Re: Number.isNaN

2012-12-14 Thread John-David Dalton
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

Re: Number.isNaN

2012-12-14 Thread Brendan Eich
This boxed-primitive equation is a sore point, and perhaps some API should be standardized, but Number.isNaN is not that API. That's point #1, please ack it: we must have a predicate that applies only to true NaN primitives. Point #2 is that we haven't heard the demand for such APIs until

Re: Number.isNaN

2012-12-14 Thread Rick Waldron
On Fri, Dec 14, 2012 at 2:02 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Nathan Wall [nathan.w...@live.com] Sent: Friday, December 14, 2012 13:34

RE: Number.isNaN

2012-12-13 Thread Luke Hoban
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton Subject: Number.isNaN I noticed that ES6  `Number.isNaN` checks `Type(number)` of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper

Re: Number.isNaN

2012-12-13 Thread Mark S. Miller
On Thu, Dec 13, 2012 at 7:50 PM, Luke Hoban lu...@microsoft.com wrote: From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of John-David Dalton Subject: Number.isNaN I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it make sense

Re: Number.isNaN

2012-12-13 Thread Yusuke Suzuki
The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So Number.isNaN(Object(NaN)) will return true. Global's isNaN uses ToNumber, but Number.isNaN doesn't do it because type coercion makes confused result, such as `isNaN(Object(NaN))` = true [0] So

RE: Number.isNaN

2012-12-13 Thread Luke Hoban
From: Mark S. Miller [mailto:erig...@google.com] 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

Re: Number.isNaN

2012-12-13 Thread John-David Dalton
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? I know `Object(NaN)` is totally edge case but it still has the brand of

Re: Number.isNaN

2012-12-13 Thread Axel Rauschmayer
Honest question: I have yet to see boxed values in practice. Are there any real use cases? [[[Sent from a mobile device. Please forgive brevity and typos.]]] Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com On 14.12.2012, at 05:18, Luke Hoban

Re: Number.isNaN

2012-12-13 Thread Mark S. Miller
On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton john.david.dal...@gmail.com 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

Re: Number.isNaN

2012-12-13 Thread John-David Dalton
No. Object.is correctly reports that these are different. Ah yap, I've had my head in lib code for a while. I'm used to the behavior of `_.isEqual(3, Object(3)); // = true` but you're right the current behavior of `Object.is(3, Object(3)); // false` so yap it makes sense that it's that way for

Re: Number.isNaN

2012-12-13 Thread John-David Dalton
Honest question: I have yet to see boxed values in practice. Are there any real use cases? See Modernizr: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23 -JDD On Thu, Dec 13, 2012 at 8:26 PM, Axel Rauschmayer a...@rauschma.de wrote: Honest question: I have

Re: Number.isNaN

2012-12-13 Thread Andreas Rossberg
On 14 December 2012 06:46, John-David Dalton john.david.dal...@gmail.com wrote: Axel Rauschmayer: Honest question: I have yet to see boxed values in practice. Are there any real use cases? See Modernizr: https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23 I think