On Feb 10, 2012, at 2:29 PM, Brendan Eich wrote: > > Some engines do use syntactic specialization, in particular I recall Rhino > doing that. But do web-facing engines that support __proto__ do that? What do > they do with o['__proto'+'__'] and the like? Anyone know?
I worried about this a bit when I first thought about this approach. However, it really doesn't matter if the behavior is tied to the semantics of the basic assignment operator. That operator gets a Reference as its RHS value so it doesn't matter if you say obj.__proto__ or obj[__proto__] or obj["__pro"+"to__"]. > >> The existence of a Object.prototype.__proto__ property (perhaps a special >> one) seems like a plausible way to do this this. On the other hand, there >> is also nothing preventing us from simply specify a new global function >> __proto__disable__ (or any other triggering mechanism we might agree on)that >> could be called to disable the __proto__ feature. > > We shouldn't go too far afield from today's code. True, SpiderMonkey has > O.p.__proto__ non-configurable, but we can and (I think) will change that so > it can be deleted. That's the shortest path to a disabling API, no need for > __mumble__ APIs. The main reason I mention the turn-off via a global function alternative, is that it in combination with a syntax linked specification eliminates the need to worry about whether O.p.__proto__ is an accessor or data property or its attribute values. It simply is not a property under that approach. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
