Ok, so (after pushing back based on recorded consensus, which I think is
fair), I'm ok with
* Object.prototype.__proto__ is configurable.
* o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's
[[SetInheritance]].
I'm not sure everyone agrees, but let's assume these two.
Why, given these, must Object.prototype.__proto__ not reflect at all via
Object.getOwnPropertyDescriptor? 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.
Re: Mark's
3) If we extend object literals with the computed name expression
square-bracket syntax, consider
{ [ e ]: .... }
where e is an expression that evaluates to the string "__proto__".
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.
I agree with Mark. This does indeed mean that
n = "__proto__";
o = { [n]: p }
will define a data property, not set inheritance. That's the only way
quoting can matter, i.e.
o = { ['__proto__']: p }
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.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
