On __proto__ as a magical data property

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jul 17 10:14:23 PDT 2012


Jeff,

There is a draft spec. for __proto__ in Section B.3.1.1 of the current ES6 draft http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts 

There is still some controversy about exactly how this spec. should be formulated and whether the Object.prototype.__proto__ manifests as a data property or an accessor property.  But I think that spec. largely reflects general agreement on other observable issues.

In particular:
      changing Object.prototype.__proto__ in any way disables the special __proto__ semantics for any object that inherits from itObject.prototype
      Object.defineOwnPropertyobj, "__proto__", ...} does not modify [[Prototype]].  You have to use [[Put]] to do that
      
Allen

On Jul 17, 2012, at 9:50 AM, 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 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.
> 
> 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.  David Mandelin and I discussed this, and we agreed to push it to the Firefox tree to get that data.  We can always back it out if necessary.
> 
> Jeff
> 
> 0. https://bugzilla.mozilla.org/show_bug.cgi?id=770344 Note that I didn't implement the restrictions of the wiki proposal, just a straight reimplementation.  This is *only* to test the as-accessor proposition.  If the wiki's restrictions are deemed desirable, they can be implemented atop this patch.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120717/a6e85891/attachment.html>


More information about the es-discuss mailing list