<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 9:42 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, so (after pushing back based on recorded consensus, which I think is fair), I'm ok with<br>
<br>
* Object.prototype.__proto__ is configurable.<br>
<br>
* o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's [[SetInheritance]].<br>
<br>
I'm not sure everyone agrees, but let's assume these two.<br>
<br>
Why, given these, must Object.prototype.__proto__ not reflect at all via Object.<u></u>getOwnPropertyDescriptor?</blockquote><div><br></div><div style>What? Where is that proposed? (And again, I am jumping into this thread in the middle, so apologies for lack of context.)</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What about Object.getOwnPropertyNames? We have to sink some cost somewhere, and TC39 had a January near-consensus of "accessor, with get and set functions that throw on cross-realm |this| vs. the accessor function". That seems the best solution to me still, and it should fall out of cross-window/frame wrapper policy hooks fairly cheaply in SpiderMonkey.<br>
</blockquote><div><br></div><div style>That sounds good to me too. Where is the alternative explained?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Re: Mark's<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 3) If we extend object literals with the computed name expression <br>
</blockquote>
square-bracket syntax, consider<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
     { [ e ]: .... }<br>
<br>
 where e is an expression that evaluates to the string "__proto__". <br>
</blockquote>
This *must not* fall into the equivalent of the syntactic special case. To do so is to move the encoding error of #2 from code-generating programs to regular JS reflective programs.<br>
<br></div>
I agree with Mark. This does indeed mean that<br>
<br>
  n = "__proto__";<br>
  o = { [n]: p }<br>
<br>
will define a data property, not set inheritance. That's the only way quoting can matter, i.e.<br>
<br>
  o = { ['__proto__']: p }<br>
<br>
defines a plain old data property. No need to mimic JSON and make a quoted vs. unquoted difference without the [] for computed property names. Making that change requires a search of the web to find disproof, which is never a complete search, which leaves us hanging and makes implementors unhappy to take unknown risk.<div class="HOEnZb">
<div class="h5"><br>
<br>
/be<br>
______________________________<u></u>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<u></u>listinfo/es-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Text by me above is hereby placed in the public domain<br><br>  Cheers,<br>  --MarkM
</div></div>