[Standardizing The Magic __proto__ Property] feedback
bruant.d at gmail.com
Sat Jan 7 04:28:44 PST 2012
I have some feedback on the strawman in its current form.
First, a cosmetic one, at 4. is written "...(FF already acts this way,
so my previous message was wrong in claiming that Object.create(null)
fails to avoid this platform on all non-IE browsers.)". I think this is
a left-over from a copy/paste of the initial email.
The strawman often refers to "context" or "frame" (item 5,
[[ProtoSetter]] step 2) and I'm not sure this notion is defined in
ECMAScript. Could a definition be added?
"The previous item presents a problem for proxies. With __proto__'s
setter being normative optional, should proxies also have a normative
optional trap for attempts to set their [[Prototype]]? If so, then
presumably there should also be such an operation in that context's
@reflect module. In that case, it no longer clear what to do to lock
down a context so that the [[Prototype]] of its objects can no longer be
=> A broader question is whether __proto__ is meant to stay.
__proto__ started as a Mozilla-specific thing, later added by
Mozilla had the project to remove it . It generated a long thread
started by John-David Dalton ("Standardizing __proto__"). One notable
answer by Brendan  suggested a plan to eventually get rid of __proto__.
Some recent information  tells us that the mobile ecosystem is
dominated by __proto__-capable browsers. As a consequence, in mobile,
some authors would take __proto__ for granted. So much that Microsoft
would be considering to implement it, thus re-questionning the intention
to eventually get rid of __proto__.
If __proto__ is meant to stay, considering adding a normative optional
trap and a function in the @reflect module seems necessary. If __proto__
is only codified for the purpose of aligning current implementations for
better security&interoperability with the eventual intention to get rid
of it according to the plan Brendan described, then the trap and
@reflect functions do not seem necessary.
I think that the question is: is __proto__ meant to stay?
An alternative to __proto__ as optional normative could be __proto__ as
optional normative in ES5 and disabled for ES6 (but it would require an
opt-in different from "use strict"; since ES5 strict mode and __proto__
currently coexist in some browsers)
=> Current implementations prevent prototype chain cycles, the
algorithm, as described doesn't seem to prevent this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss