[Standardizing The Magic __proto__ Property] feedback

David Bruant bruant.d at gmail.com
Sat Jan 7 04:28:44 PST 2012


Hi,

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
mutated."
=> A broader question is whether __proto__ is meant to stay.
__proto__ started as a Mozilla-specific thing, later added by
JavaScriptCore, V8 and Opera engine.
Mozilla had the project to remove it [1]. It generated a long thread
started by John-David Dalton ("Standardizing __proto__"). One notable
answer by Brendan [2] suggested a plan to eventually get rid of __proto__.
Some recent information [3] 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)


[[ProtoSetter]] algorithm
=> Current implementations prevent prototype chain cycles, the
algorithm, as described doesn't seem to prevent this.

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=642500
[2] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013162.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2011-December/019083.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120107/1e53e16b/attachment.html>


More information about the es-discuss mailing list