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
