d at domenic.me (2015-04-19T23:44:19.420Z)
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.
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>