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 <[email protected]> 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 <[email protected]> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
