Re: Number.isNaN
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 equivalance operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. I'm happy to read that the unintentional dual zeroes issue is being considered by committee members. My attempt to raise this issue two weeks back (Object.is(0,-0) and its data structures implications https://mail.mozilla.org/pipermail/es-discuss/2012-December/026794.html) didn't generate any public responses, however multiple people responded privately about it. Thanks! /Olov ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
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 Number
wrapper instance also returned true when passed as the argument for
Number.isNaN.
Why is it needed? Can't we just simply do:
function isReallyNaN(o) {
return o!=oisNaN(o);
}
I don't get the point of detecting Object(NaN) since it's type is an object
not number.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
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 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 Number.isNaN.
Why is it needed?
If anything, to explain devs that isNaN is broken and they should move
to Number.isNaN.
Can't we just simply do:
function isReallyNaN(o) {
return o!=oisNaN(o);
}
o!=o will be enough I think. You've got a polyfill :-)
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
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:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23
I think not. And wrapping bools, like the above piece of code does, is
a particularly bad idea, because JS says
(Object(false) ? 1 : 2) === 1
Fortunately, I think that bit of code never returns Object(false),
because the `if` fails first, and just plain `false` is returned.
Really, since objects are truthy, `new Boolean(bool)` there could be
replaced with `{}`. Or, the whole body of the `if` could just be an
object literal.
Sam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 Number.isNaN. Arguably, the Type test in the draft is redundant, but may be clarifying. If you wanted to test for NaN-ness of either Number values or Number wrappers then the appropriate thing would be to make isNaN an method of Number.prototype. Allen On Dec 13, 2012, at 7:19 PM, John-David Dalton wrote: I noticed that ES6 `Number.isNaN` checks `Type(number)` of Number, would it make sense to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? - JDD ___ 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
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 !== myNaN`. On Fri, Dec 14, 2012 at 8:39 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: 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 ===. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 = 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
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 On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall 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
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 john.david.dal...@gmail.com 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. -JDD On Fri, Dec 14, 2012 at 9:12 AM, Nathan Wall 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 https://mail.mozilla.org/listinfo/es-discuss
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 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
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 `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 people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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.
I love how the thread got sidetracked by that one ;D
Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore have
`isXyz` methods or equivalents that equate boxed and unboxed values as
similar:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed alike in their `isXyz`
I think the spec should follow.
On Fri, Dec 14, 2012 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote:
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.commailto:
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-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( That is sad indeed :( Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 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 people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds. 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 operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. Allen There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ 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
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 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 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 people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds. 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 operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. Allen There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 `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 people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( Restricted productions creating new operators may be at risk (Allen's right, we haven't had an orderly decision in TC39 on this point), but Object.is or Object.isSameValue is definitely not dead. Allen's right too that we have some disagreement on the use of SameValue under the hood in Map and Set. /be (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ 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
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 or equivalents that treat boxed and unboxed values as like:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both return
`true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` both
return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge (`-0`
anyone).
Because the majority of libs treat boxed and unboxed the same in their
`isXyz` I think it's natural for the spec to follow in the case of
`Number.isNaN`.
Thanks,
-JDD
On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
[es-discuss-bounces@mozilla.**orges-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 `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
people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6
shims environment.
`is` operator is dead :( :( :(
Restricted productions creating new operators may be at risk (Allen's
right, we haven't had an orderly decision in TC39 on this point), but
Object.is or Object.isSameValue is definitely not dead.
Allen's right too that we have some disagreement on the use of SameValue
under the hood in Map and Set.
/be
(Someone want to find a link to the minutes that killed it? I keep having
to correct people on this.)
There's not an `isNull` or `isUndefined`. The only reason `isNaN` was
needed was because `===` didn't work with `NaN`, but `is` does.
This is pretty reasonable, actually. The only argument I can see is that
`array.filter(Number.isNaN)` is shorter than `array.filter(x =
Object.is(x, NaN))`.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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.
That means no ES6 late exception-granting, and for a Harmony strawman
(ES7 or later) we would need to study the use-cases and exactly API
details more closely. Mostly the use-cases, to see whether something
important happens in the context of a given library or its folkways
that won't -- or should not -- happen in the standardized core language.
Not all libraries have cowpaths that we want to pave. For one thing,
libraries conflict. For another, some have design flaws.
/be
John-David Dalton wrote:
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 or equivalents that treat boxed and unboxed
values as like:
For example:
Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both
return `true` also `_.isEqual('hi', Object('hi'))` returns `true`
MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))`
both return `true`
jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
`Object(NaN)` is edge case, but lots of things in the spec are edge
(`-0` anyone).
Because the majority of libs treat boxed and unboxed the same in their
`isXyz` I think it's natural for the spec to follow in the case of
`Number.isNaN`.
Thanks,
-JDD
On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org
mailto:es-discuss-boun...@mozilla.org
[es-discuss-boun...@mozilla.org
mailto:es-discuss-boun...@mozilla.org] on behalf of
Nathan Wall [nathan.w...@live.com
mailto: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 `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 people to use `x is NaN` in ES6 or `Object.is(x,
NaN)` in an ES3/5 + ES6 shims environment.
`is` operator is dead :( :( :(
Restricted productions creating new operators may be at risk
(Allen's right, we haven't had an orderly decision in TC39 on this
point), but Object.is or Object.isSameValue is definitely not dead.
Allen's right too that we have some disagreement on the use of
SameValue under the hood in Map and Set.
/be
(Someone want to find a link to the minutes that killed it? I
keep having to correct people on this.)
There's not an `isNull` or `isUndefined`. The only reason
`isNaN` was needed was because `===` didn't work with
`NaN`, but `is` does.
This is pretty reasonable, actually. The only argument I can
see is that `array.filter(Number.isNaN)` is shorter than
`array.filter(x = Object.is(x, NaN))`.
___
es-discuss mailing list
es-discuss@mozilla.org mailto: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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
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 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 people to use `x is NaN` in ES6 or `Object.is(x, NaN)` in an ES3/5 + ES6 shims environment. `is` operator is dead :( :( :( (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.) I may be wrong, but I don't think it was ever formally killed by TC39. I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting. That's why I haven't deleted the is operator from the draft yet. It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds. Confirmed. There is no such discussion on record from a TC39 meeting. Someone said out loud at the last meeting but it never made it to the agenda. I will formally add it to the agenda for January Rick 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 operator for Map/Set?, and the question about the need for Number.isNaN if we have Object.is available. ps. These too. Allen There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does. This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x = Object.is(x, NaN))`. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So Number.isNaN(Object(NaN)) will return true. Luke [0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Number.isNaN
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 to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So Number.isNaN(Object(NaN)) will return true. 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 Luke [0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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] So Number.isNaN(Object(NaN)) will return false in latest draft and isNaN(Object(NaN)) will return true. [0] http://wiki.ecmascript.org/doku.php?id=harmony:number.isnan On Fri, Dec 14, 2012 at 12: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 to instead check that the [[BuiltinBrand]] is BuiltinNumberWrapper similar to `Array.isArray`'s check. This would also allow `Number.isNaN(Object(NaN))` to return `true`. Thoughts? The current draft spec [0] uses a ToNumber coercion and checks whether this results is NaN. So Number.isNaN(Object(NaN)) will return true. Luke [0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 BultinNumberWrapper and is NaN (boxed).
On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban lu...@microsoft.com wrote:
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
'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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 lu...@microsoft.com wrote: 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 '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 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
Re: Number.isNaN
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 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 lu...@microsoft.com wrote:
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
'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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 `NaN` and `Object(NaN)`
as well.
On Thu, Dec 13, 2012 at 8:36 PM, Mark S. Miller erig...@google.com wrote:
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
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 lu...@microsoft.com wrote:
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
'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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 a...@rauschma.de wrote: 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 lu...@microsoft.com wrote: 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 '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 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
Re: Number.isNaN
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 not. And wrapping bools, like the above piece of code does, is a particularly bad idea, because JS says (Object(false) ? 1 : 2) === 1 /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
