brendan at mozilla.org
Fri Feb 10 11:24:07 PST 2012
Hi Tom, this may repeat parts of replies from others, if so please bear
I think __proto__ should be a bit magical, and in particular should not
be proxy-able. Annex B is becoming "Normative Optional", meaning you are
not required to implement its contents to conform to ECMA-262, but if
you do support the specified APIs, then Annex B's spec is normative.
For __proto__ we do not need to over-specify (as we generally do
elsewhere, for interoperation). The appearance of a data property
matches some implementations today and it could be spec'ed as Allen
wrote up. This adds some risk to the main spec and proxies, but if we do
not want __proto__ to be proxy-able then it might be the right approach.
The temptation to polish __proto__ to fit the spec and language is high
but my gut says we should resist it. We may help enshrine it in ways we
do not want (proxies). We may err in inventing a new de-jure spec that
does not match existing implementations.
Tom Van Cutsem wrote:
> I'm also in favor of exposing __proto__ as an accessor on the grounds
> that it is least magical. I'm worried that the changes made here to
> the core internal methods [[Get]], [[Put]], [[DefineOwnProperty]] and
> [[Delete]] will give proxies a hard time to properly emulate this
> behavior if they would want to do that. How would a proxy handler be
> able to access the internal variable UnderscoreProtoEnabled?
> (I currently assume that in any event, aProxy.__proto__ would just
> trigger the "get" trap for "__proto__" and that all of this magical
> behavior does not apply to proxies, only built-in normal objects.)
> Also +1 to Gavin's proposed alternative to the frame-check.
> 2012/2/10 Gavin Barraclough <barraclough at apple.com
> <mailto:barraclough at apple.com>>
> On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote:
>> I would expect Gavin's approach to ultimately be even worse than
>> mine from a semantic analysis perspective. It expose (via
>> Object.getOwnPropertyDescriptor) functions that have the ability
>> to mutate any object's [[Prototype]] property and one those
>> functions are exposed they can be installed as methods or
>> explicitly called at any time. I think that tame them is likely
>> to have even greater impact than what I have done. Certainly,
>> for the ES5 language level (which is what my current spec.
>> addresses) there is no way to talk about frames or the
>> association of one of these functions or any other object with a
>> frame. With my approach there is no need to match the proto
>> mutator function's frame with the target object's frame, because
>> there is no mutator function.
> Hi Allen,
> I completely agree with you that frame-based checks should not be
> a part of the solution, however they are no more necessary if
> __proto__ is an accessor property then if it is a data descriptor.
> The solution I proposed was that the [[ProtoSetter]] should hold
> a private reference to the Object Prototype upon which it is
> initially assigned, and that upon being invoked it should walk the
> this object's prototype chain to see if it any entry matches the
> stored value. With a check such as this in place (I expect there
> are other ways we could achieve this), it would not be possible to
> apply a given [[ProtoSetter]] to any object other than those upon
> which it would initially have been available to operate via the
> Object Prototype.
>> Finally there is the object literal issue which was not address
>> by the original wiki proposal.
> You're right, we do need to expand the proposal to cover this.
> This doesn't seem too difficult. If the identifier being
> assigned to in an object literal initialization is "__proto__",
> then check whether the Object Prototype contains a property
> named "__proto__" whose descriptor has a "set" value equal to that
> Object Prototype's original [[ProtoSetter]] function, if so then
> the assignment sets the newly constructed object's prototype,
> otherwise it defines a own property as usual.
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss