<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 1:59 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Tue, May 7, 2013 at 1:52 PM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen.wirfsbrock@gmail.com" target="_blank">allen.wirfsbrock@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">

So here is the plan that I'll review at the next TC39 meeting:<div><br></div><div>1) Add Object.setPrototypeOf(obj, proto)</div><div>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.  </div>

</div></blockquote><div><br></div></div><div>+1</div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><br></div><div>2) Object.prototype.__proto__ is moved back to Annex B.</div></div></blockquote><div><br></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">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</span></div>
</div></div></div></blockquote><div><br></div><div style>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>
</div><div class="im"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div> 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__".</div>

</div></blockquote><div><br></div></div><div>+1</div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><br></div><div>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__. </div>

</div></blockquote><div><br></div></div><div>I hadn't thought about this irregularity if it appears within a class definition. That aside, +1.</div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><br></div><div>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.</div>

</div></blockquote><div><br></div></div><div>+1. Excellent!</div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>Allen</div></font></span><div><div><div><br><div><div>On May 7, 2013, at 12:18 PM, Mark Miller wrote:</div><br></div></div>
</div></div></div></blockquote></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div></div>