Mutable Proto

David Bruant bruant.d at
Wed Mar 20 09:18:46 PDT 2013

Le 20/03/2013 16:36, Nathan Wall a écrit :
> 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.
Could you describe how you use __proto__ on objects not inheriting from 

 From what I know there are 2 main use cases:
1) object as map
changing the prototype enable changing different "default values". I 
guess any solution to that problem either looses the object syntax 
(maybe unless using proxies) like using an ES6 Map or has non-trivial 
runtime cost.
Or the code needs to be reorganized so that the object is always created 
after the prototype (using Object.create for instance)

2) Subclassing
ES6 will have classes with inheritance. That's mostly syntax sugar on 
top of what's already possible, but that works.

Do you have a use case that belongs in neither of these categories?


> Nathan
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list