I don't expect big performance gains from making __proto__ non-overwritable. In non-optimized code you have to check the prototype chain in case the prototype objects (not their identity) have been changed. In the case of optimized code you can fall back to nonoptimized code if someone writes to __proto__. So it wouldn't make all that much difference, at least in V8-Crankshaft.
On the other hand I am very leery of breaking pages that used to work. Of course it is a blessing in this case that IE never adopted this particular misfeature of the language, but our experience with making backwards incompatible changes is that you can't do it without breaking part of the web. It's IMHO an illusion to think that you can enumerate all uses of a feature before you break it, and I think it is even an illusion to think that everyone will complain to you after you break it. They (developers and users) will just sigh and think to themselves that the web is a substandard platform on which things that used to work suddenly stop working. I can't see us leading the way on this (no surprise there). 2011/3/19 John-David Dalton <[email protected]>: >> We still need to serve the preset-proto use cases, for sure. > > I think that's what I am championing for (something that allows > setting [[Prototype]] on creation like Object.subclass() )? > If so then we are on the same page \o/ > > -JDD > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
