Mutable Proto

Nathan Wall nathan.wall at
Wed Mar 20 08:36:53 PDT 2013

I didn't get a direct response to my question about mutating proto on objects which don't inherit from Object.prototype, but I'm inferring from [1] that it won't be possible.  I find this unfortunate, but I realize this issue has seen a lot of discussion in the past and there are reasons for the current decision.  I will see how I can make my code cope with reality.


Brendan Eich wrote:
> 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
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list