Hi Tom, this may repeat parts of replies from others, if so please bear
with me:
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.
/be
Tom Van Cutsem wrote:
Hi,
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.
Cheers,
Tom
2012/2/10 Gavin Barraclough <[email protected]
<mailto:[email protected]>>
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.
cheers,
G.
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
