On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich <[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. I like your proposal because I think the intra-frame protection it provides is nice. But I don't think it is essential. If __proto__ does reflect as an accessor as currently stated in the strawman, with the inter-frame restriction, I think that would be ok. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
