Mark S. Miller wrote:
On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
I don't think we should change __proto__ unnecessarily from
current implementations, including making it an accessor. Neither
JSC nor SpiderMonkey does that.
We do need the ability to delete it, so it should live on
Object.prototype and be configurable.
Ignoring the "don't gild the lily" (or "don't polish the turd")
advice above, if we *do* reflect __proto__ as an accessor, then
the same-frame problem still exists. Perhaps it can be solved by
proxies, but why require that?
I didn't follow that. The current strawman
<http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property>
says in step 2 of [[ProtoSetter]]:
2. If O is not an object from this context, throw a
*TypeError* exception.
I don't say anything about how this test is performed because we don't
yet know how we'll represent the extra bookkeeping needed to spec the
interaction of multiple globals. This is inter-frame protection only.
Yes, that's why I wrote "the same-frame problem still exists".
I like your proposal because I think the intra-frame protection it
provides is nice. But I don't think it is essential.
It's hard to prove what is essential, but my "proxies" point was to ask:
must membranes be used to protect here, when the pseudo-data-property
approach relieves us of any such requirement?
If __proto__ does reflect as an accessor as currently stated in the
strawman, with the inter-frame restriction, I think that would be ok.
It's ok but I think the pseudo-data way is "more ok" ;-).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
