brendan at mozilla.org
Sat Jan 28 23:30:15 PST 2012
Mark S. Miller wrote:
> On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich <brendan at mozilla.org
> <mailto:brendan at mozilla.org>> 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
> 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" ;-).
More information about the es-discuss