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.
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>
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] bugzilla.mozilla.org/show_bug.cgi?id=642500 [2] esdiscuss/2011-March/013162 [3] esdiscuss/2011-December/019083
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>