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

Mark S. Miller erights at
Mon Apr 13 15:37:50 UTC 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list