Re: Number.isNaN

Le 18/12/2012 14:43, gaz Heyes a écrit : On 14 December 2012 16:39, Allen Wirfs-Brock > 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 defi

Re: Number.isNaN

On 14 December 2012 16:39, Allen Wirfs-Brock 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 Number > wrapper insta

Re: Number.isNaN

2012/12/14 Allen Wirfs-Brock > 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 equivalance operato

Re: Number.isNaN

On Fri, Dec 14, 2012 at 2:02 PM, Allen Wirfs-Brock wrote: > > 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

Re: Number.isNaN

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 now.

Re: Number.isNaN

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 o

Re: Number.isNaN

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

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 wrote: > > On Dec 14, 2012, at 10:45 AM,

Re: Number.isNaN

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

RE: Number.isNaN

> > 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 j

Re: Number.isNaN

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 projects

RE: Number.isNaN

> 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

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 pe

Re: Number.isNaN

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 lib

Re: Number.isNaN

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 http

Re: Number.isNaN

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 wrote: >> But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. > > That's my point. Normally testing for NaN can be done vi

Re: Number.isNaN

> 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

> 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 = Obj

Re: Number.isNaN

> 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

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 Nu

Re: Number.isNaN

On Fri, Dec 14, 2012 at 2:43 AM, Andreas Rossberg wrote: > On 14 December 2012 06:46, John-David Dalton > 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/bl

Re: Number.isNaN

On 14 December 2012 06:46, John-David Dalton 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 not. And wrapping bo

Re: Number.isNaN

> 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 wrote: > Honest question: I have yet to see boxed

Re: Number.isNaN

> 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

On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton 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. Ob

Re: Number.isNaN

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 wrote: >>> F

Re: Number.isNaN

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 Bu

RE: Number.isNaN

>> 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 th

Re: Number.isNaN

> > 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]

Re: Number.isNaN

On Thu, Dec 13, 2012 at 7:50 PM, Luke Hoban 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 to in

RE: Number.isNaN

>> 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 >> BuiltinNumber