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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss