brendan at mozilla.org
Fri Feb 10 14:29:33 PST 2012
Allen Wirfs-Brock wrote:
> On Feb 10, 2012, at 11:24 AM, Brendan Eich wrote:
>> Hi Tom, this may repeat parts of replies from others, if so please bear with me:
>> I think __proto__ should be a bit magical, and in particular should not be proxy-able. Annex B is becoming "Normative Optional", meaning you are not required to implement its contents to conform to ECMA-262, but if you do support the specified APIs, then Annex B's spec is normative.
> A different approach is to tie the semantics to language syntax instead of making it part of the "virtual machine" that is defined by the internal methods. For example, I could specify the [[Prototype]] mutating behavior of an assignment to the __proto__ property as an extension to the evaluation semantics of the simple assignment operator (11.13.1). An advantage to doing it this way is that it can only be trigger by using that specific syntactic form. In particular, other syntactic constructs that in do [[Put]]'s and all the [[Put]]'s in built-in and host functions would not trigger it.
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?
> The approach I took in my proposal for the handling of __proto__ in object literals is another example of this syntactic approach.
That case needs special handling, and the syntax can be specialized
there without loss of generality.
> 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.
> We can under specify Object.prototype.__proto__ but doing so clearly opens up the at least the possibility of hypothetical interpretability issues of the sort we have historically tried to eliminate from the specificatiion. The fact, that nobody has brought forward any examples of such interoperability problems among the current somewhat divergent implementations of __proto__ shows th't the current differences aren't an issue so we could probably get away with it. But it does seem like a slippery slope. If we decide it is ok to under-specify here what about the next time there is a difference of option or preference about the edge cases manifested by some new functionality (say, just as an example, closure capture in the initializer expressions of for(let;;) loops). Are we going to be more inclined to just under-specify? I hope not.
Not for normative-mandatory stuff. For normative-optional, maybe.
Consider that engines still feel the need to support foo.arguments.
We've never spec'ed that even informatively.
More information about the es-discuss