github at esdiscuss.org (2013-07-12T02:27:21.464Z)
On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller <erights at google.com> wrote: > On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock <allen.wirfsbrock at gmail.com> wrote: > >> 2) `Object.prototype.__proto__` is moved back to Annex B. > > > Since `__proto__`, unlike `__defineGetter__`, provides functionality that is > otherwise unavailable, all JS platforms will treat it as mandatory whether > we put it into Appendix B or the main text. At this point, I think moving > this back to Appendix B would be an obviously meaningless gesture > My "since" is incorrect, as the functionality is available via `Object.setPrototypeOf`. Nevertheless, I still think this would be a meaningless gesture. OTOH, since it is meaningless, it is also mostly harmless.
On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller <erights at google.com> wrote: > On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock < > allen.wirfsbrock at gmail.com> wrote: > >> So here is the plan that I'll review at the next TC39 meeting: >> >> 1) Add Object.setPrototypeOf(obj, proto) >> A obj must be extensible in order to change its [[Prototype]]. There are >> no realm restrictions. It's just like all the other Object.* methods in >> operating on any object, independent of realm association. >> > > +1 > > > >> >> 2) Object.prototype.__proto__ is moved back to Annex B. >> > > Since __proto__, unlike __defineGetter__, provides functionality that is > otherwise unavailable, all JS platforms will treat it as mandatory whether > we put it into Appendix B or the main text. At this point, I think moving > this back to Appendix B would be an obviously meaningless gesture > My "since" is incorrect, as the functionality is available via Object.setPrototypeOf. Nevertheless, I still think this would be a meaningless gesture. OTOH, since it is meaningless, it is also mostly harmless. > > > > > >> It is defined as an accessor property with attributes {enumerable: true, >> configurable: true}. The get and set functions are defined equivalently to >> Object.setPrototypeOf and Object.getPrototypeOf. No realm restrictions. >> No reflection restrictions. Object.getOwnPropertyNames(Object.prototype) >> includes "__proto__". >> > > +1 > > > >> >> 3) __proto__ as a property key in an object literal (but not a class >> definition) is syntax with special semantics of setting the literal >> object's [[Prototype]] when it is created. It is a clause 11 feature and >> is not tied to the presence of Object.prototyype.__proto__. >> > > I hadn't thought about this irregularity if it appears within a class > definition. That aside, +1. > > > >> >> 4) Both Object.setPrototypeOf and Object.prototype.__proto__ are defined >> in terms of the [[SetInheritance]]/[[GetInhertiance]] MOP operations (the >> names can still change). There are corresponding Proxy traps. There are >> no exceptional restrictions placed on the handlers. Just the normal >> invariants. In particular, if the target is non-extensible then the >> [[SetInheritaqnce]] Proxy handler can't change the observable >> [[GetInhertance]] result for the proxy object. >> > > +1. Excellent! > > > >> >> Allen >> >> On May 7, 2013, at 12:18 PM, Mark Miller wrote: >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/97952e13/attachment.html>