John-David Dalton john.david.dalton at
Fri Dec 14 12:49:35 PST 2012

I apologize for the duplicate post, but I think my reply got lost in its

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

> Domenic Denicola wrote:
>> From: es-discuss-bounces at [es-discuss-bounces at mozilla.**org<es-discuss-bounces at>]
>>> on behalf of Nathan Wall [nathan.wall at]
>>> 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 ``.  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 `, 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
> 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 =>
>>, NaN))`.
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list