Standardizing __proto__

Erik Corry erik.corry at
Mon Mar 21 01:33:10 PDT 2011

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 <john.david.dalton at>:
>> 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
> es-discuss at

More information about the es-discuss mailing list