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

Mark S. Miller erights at google.com
Mon Apr 13 15:26:48 UTC 2015


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 google.com>
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
> http://jsfiddle.net/#run 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 https://code.google.com/p/chromium/issues/detail?id=476437 for the
> bug.)
>
> /Andreas
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150413/add5f760/attachment.html>


More information about the es-discuss mailing list