Mutable Proto

Brendan Eich brendan at mozilla.com
Wed Mar 20 08:15:15 PDT 2013


Mariusz Nowak wrote:
> +1!
>
> It would be great if someone will explain in detail why
> Object.setPrototypeOf is no go.

We've been over this many times, e.g. at

https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html

To recap,

1. __proto__ is out in the field, a de-facto standard on "mobile", and 
not going away. Adding another API doesn't help, it hurts.

2. SES and other secure subsets want same-frame (global object, "realm") 
mashups of code that may use __proto__ and code that must not, but 
Object.setPrototypeOf is a per-frame capability that would have to be 
removed, breaking the former class of code.


> Any function that blindly extends object with provided hash is affected e.g.
> extend(obj, { __proto__: Error.prototype }).

No, that depends on how extend works. If it uses Object.defineProperty 
or equivalent, then nothing is broken and the setter on Object.prototype 
for __proto__ is not run.

> Additionally it means that we need to serialize any user input which
> eventually may be used as key on a dictionary e.g. data[userDefinedName].

Only if you use assignment into an object that delegates to 
Object.prototype, but see (1) above: this hazard already exists. Don't 
do that; JSON doesn't, and Object.create(null) gives a way to create 
dictionaries.

Yes, the problems you cite are real, but they are already part of the 
de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a 
mistake due to (2).

/be



More information about the es-discuss mailing list