Someone should probably ask me to just write the appropriate spec language :-)
On Feb 9, 2012, at 10:53 AM, Luke Hoban wrote:
> My takeaway from this thread is that there is support for the proposed
> __proto__ semantics on the wiki [1], with a few modifications/additions. Are
> the following a correct summary of the deltas?
>
> *** Accessor vs. Data property
> Although there does not appear to be a direct security implication of
> exposing Object.prototype.__proto__ as a true accessor property, there is a
> desire to be conservative about exposing new __proto__ capabilities beyond
> what is actually defacto available on browsers today. As a result, the
> initial value of __proto__ should appear as a data property to developers,
> but remain internally an accessor property.
Saying it is internally an accessor property really is describing one possible
implementation. The real semantics would be that [[Put]]/[[Get]] of
"__proto__" has the appropriate side-effects (conditional upon presence of
original Object.prototype.__proto__"). You can implement that anyway you want
as long as it has those semantics.
>
> *** Object literals
> The wiki does not currently discuss the semantics of __proto__ in object
> literals. Given the desire to allow __proto__ to be removed, it seems more
> details are needed to nail down what this does:
but clearly {__proto__: obj} is needed for web interoperability
>
> delete Object.prototype.__proto__
> { __proto__: {x: 1} }
>
> I believe there are two options:
> (1) __proto__ in object literals always sets the [[Prototype]], irrespective
> of the value of Object.prototype.__proto__ or
> (2) __proto__ is treated as a [[Put]] instead of a [[DefineProperty]] in the
> Object Intialiser rules
>
> The second option appears more inline with the goals of the wiki proposal.
But we don't want {__proto__: 12} to change its standard [[DefineOwnProperty]]
behavior if Object.prototype.__proto__ has been deleted. this suggests a third
option:
(3) __proto__ If the enabling Object.prototype.__proto__ property is present
then __proto__ in object literals has the same [[Put]] semantics as an
assignment to __proto__
>
> When there are multiple __proto__ in an object literal, I believe it has been
> suggested that this produce a SyntaxError.
Duplicate data properties definitions always throw in ES5 strict code and the
last definition is used in non-strict code.
{__proto__: a, __proto__: b} is a legal non-strict object literal that whose
__proto__ property has the value of b.
You can make it a early SyntaxError as part of this extension but cause where
it is a [[Prototype]] modifier or just a regular property definition is
dynamically defined. I suggest that you just follow the ES5 non-strict rules
and use the last definition
>
> *** JSON
> I believe there is a requirement that JSON.parse('{"__proto__": {}}') return
> an object with an own data property named __proto__ whose value is {}.
yes!!
> Browsers currently disagree on this though.
Any that mutate [[Prototype]] in this case are introducing a new and extension
that should be strongly swatted down.
>
> Thanks,
> Luke
>
> [1] http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property
>
>
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
