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

Jordan Harband ljharb at gmail.com
Mon Apr 13 19:53:55 UTC 2015


Please note that the `@@toStringTag` changes mean that we do need to always
have a Number.prototype method that throws when the value does not have
a [[NumberData]] internal slot - I'm using `Number#toString` for that right
now, but others may now be relying on the throw behavior of `Number#valueOf.

On Mon, Apr 13, 2015 at 8:50 AM, Mathias Bynens <mathias at qiwi.be> wrote:

> CCing Piotr.
>
> On Mon, Apr 13, 2015 at 5:37 PM, Mark S. Miller <erights at google.com>
> 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
> > Object.prototype.toString.call(null) 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 google.com>
> 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 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
> >>>
> >
> >
> > --
> >     Cheers,
> >     --MarkM
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150413/dd1cf0e2/attachment-0001.html>


More information about the es-discuss mailing list