On __proto__ as a magical data property

Brendan Eich brendan at mozilla.org
Tue Jul 17 11:37:44 PDT 2012

Jeff Walden wrote:
> If __proto__ were a magical data property, what would happen if you did:
>    Object.defineProperty(Object.prototype, "__proto__", { writable: false });
> and then later:
>    ({}).__proto__ = Object.prototype; // non-mutating "mutation"
> or
>    ({}).__proto__ = {}; // mutating mutation
> or for that matter
>    Object.prototype.__proto__ = null; // non-mutating "mutation"
> or
>    Object.prototype.__proto__ = Object.create(null); // mutating mutation

I don't know what you mean by "mutating mutation". In no case is the 
non-writable magic property's internal setter called. Right?

> I spent a little time experimenting implementing __proto__ as an accessor property to see how the issues previously raised -- proxies, cross-global objects, and so on -- actually played out.  It required surprisingly few special-case behaviors.  SpiderMonkey's existing wrapper/proxy mechanism addresses those issues (through the "nativeCall" trap, if you're curious) without special effort.

That's nice but it doesn't address the argument that ECMA-262, not a 
certain implementation, should not expose a usable setter at all (never 
mind wrapped and monitored).

You'd be on stronger ground if you poisoned the reflection API so the 
setter could not be extracted.

> More data's always helpful, and because Firefox is at the start of a development cycle, now is the ideal time to get it.  There's no substitute for data.

Data sounds impressive but if you're seeking proof of compatibility, you 
can only get confirmation that the change is not compatible.

Proving the change is compatible isn't really possible with "data", but 
data is not the first issue that led TC39 to agree to spec __proto__ as 
a magic data property.

What's driving this desire for an accessor? Aesthetics are not a good 
motivation. One fewer magic data property in the language still leaves 
magic data properties in the language, notably Array length.


More information about the es-discuss mailing list