Standardizing __proto__

Brendan Eich brendan at
Fri Mar 18 12:59:17 PDT 2011

On Mar 18, 2011, at 10:02 AM, John-David Dalton wrote:

>> For symmetry with
>> Object.create, you might want Boolean.create, Date.create and so
>> forth, but that's still initialization-time, and TBH I would be
>> surprised if there were actually many collisions between libraries
>> that augment those prototypes.
> In the Script Junkie article I cover a few examples of collisions with
> Function.prototype's and problems with Array.prototype.
> Date.create, Function.create and the like clutters the API. I would be
> for a more generic Object.setPrototypeOf() addition.

You are missing shaver's point that initiializing is not the same as reassigning later on a created and reachable object.

We really do not want to support reassignment in our implementation, and I suspect other implementors feel the same. It's a sunk cost, but see the sunk-cost fallacy. Nothing is free, people still pay with security attack surface and consequent (both friendly fuzzers and bad actors attack that surface) bug fixing.

>> and I can't really find anything other than Fuse that uses
>> it on the web today
> PrototypeJS uses it.

Prototype gets __proto__ but AFAICS does not set it.

>> I think you can also achieve what you want with Harmony proxies, so
>> you'll have that option in the next edition of ES.
> I don't know. It would need to preserve internal [[Class]] as __proto__.

Proxies may help some use-cases. They are not a solution if you want a one-off delegation chain from a non-proxy to another object.


More information about the es-discuss mailing list