brendan at mozilla.com
Fri Dec 14 14:02:48 PST 2012
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
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.
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
> On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich <brendan at mozilla.com
> <mailto:brendan at mozilla.com>> wrote:
> Domenic Denicola wrote:
> From: es-discuss-bounces at mozilla.org
> <mailto:es-discuss-bounces at mozilla.org>
> [es-discuss-bounces at mozilla.org
> <mailto:es-discuss-bounces at mozilla.org>] on behalf of
> Nathan Wall [nathan.wall at live.com
> <mailto:nathan.wall at 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.
> (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 at mozilla.org <mailto:es-discuss at mozilla.org>
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss