Number.prototype not being an instance breaks the web, too

Mathias Bynens mathias at
Mon Apr 13 15:50:26 UTC 2015

CCing Piotr.

On Mon, Apr 13, 2015 at 5:37 PM, Mark S. Miller <erights at> wrote:
> Hold on. I may have reacted too quickly. If it is only jsfiddle, since this
> is an online service rather than a widely copied library, they could just
> fix it. OTOH, if it really is a mootools issue, then yes, we really do need
> to change the spec. (History: Facebook fixed JSON incompatibility. ES5 fixed
> incompat with jQuery.)
> Could someone please reply-all to this thread cc'ing Piotr Zalewa and Oskar
> Krawczyk? Thanks.
> On Mon, Apr 13, 2015 at 8:26 AM, Mark S. Miller <erights at> wrote:
>> I agree. With Number.prototype joining Array.prototype and
>> Function.prototype on the dark side, we should ask which others should too.
>> When it was only Function.prototype and Array.prototype, principle of least
>> surprise (POLS) had us keep the list as small as possible -- until we had
>> precisely this kind of evidence of incompatibility. From a security pov, the
>> important ones not to revert are those carrying mutable state not locked
>> down by Object.freeze. In ES5 this was only Date.prototype. Of the ES5
>> builtins in ES6, this now includes RegExp.prototype because of
>> RegExp.prototype.compile. (Because of de facto stack magic, this might
>> include Error.prototype as well.) Fotunately, there is still no evidence
>> that we need to corrupt these as well.
>> OTOH, POLS still says that almost everything should not go to the dark
>> side, for consistency with ES6 classes. So the precise line becomes a matter
>> of taste. I propose that the co-corrupted list be
>> Function.prototype
>> Array.prototype
>> Number.prototype
>> Boolean.prototype   // No incompat data. Only POLS
>> String.prototype       // No incompat data. Only POLS
>> since Number, Boolean, and String are the ordinary ES5 wrappers of
>> primitive data values.
>> For builtins that are new with ES6, clearly there's no compat issue. And
>> both security and consistency with ES6 classes argue in general for not
>> corrupting new things. But POLS should put very little weight on the ES5 vs
>> ES6 difference since post ES6 programmers will just see all of this as JS.
>> Given that, I could argue Symbol.prototype either way, since Symbol is
>> kinda another wrapper of a primitive type. But I prefer not. I think we
>> should keep the list to those 5.
>> Allen, process-wise, is this too late for ES6? If there's any way this fix
>> can go in ES6, it should. Otherwise, it should become the first member of
>> ES6 errata.
>> All that said, I do find corrupting only Number.prototype to be plausible.
>> I would not mind if we decided not to spread the corruption even to
>> Boolean.prototype and String.prototype. If we have to do a last minute
>> as-small-as-possible change to the spec, to get it into ES6, this might be
>> best.
>> On Mon, Apr 13, 2015 at 7:47 AM, Andreas Rossberg <rossberg at>
>> wrote:
>>> V8 just rolled a change into Canary yesterday that implements the new ES6
>>> semantics for Number.prototype (and Boolean.prototype) being ordinary
>>> objects. Unfortunately, that seems to break the web. In particular
>>> fails to load now.
>>> What I see happening on that page is a TypeError
>>> "Number.prototype.valueOf is not generic" being thrown in this function
>>> (probably part of moo tools):
>>> Number.prototype.$family = function(){
>>> return isFinite(this) ? 'number' : 'null';
>>> }.hide();
>>> after being invoked on Number.prototype.
>>> AFAICS, that leaves only one option: backing out of this spec change.
>>> (See for the
>>> bug.)
>>> /Andreas
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list