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. The approach I took in my proposal for the handling of __proto__ in object literals is another example of this syntactic approach. This sort of approach really focuses limiting the "damage" (or magic, if you prefer) to the actual source code use cases that we feel must be supported for interoperability and limits the spread of the contagion . > > For __proto__ we do not need to over-specify (as we generally do elsewhere, > for interoperation). The appearance of a data property matches some > implementations today and it could be spec'ed as Allen wrote up. This adds > some risk to the main spec and proxies, but if we do not want __proto__ to be > proxy-able then it might be the right approach. > > The temptation to polish __proto__ to fit the spec and language is high but > my gut says we should resist it. We may help enshrine it in ways we do not > want (proxies). We may err in inventing a new de-jure spec that does not > match existing implementations. But I think we do want to have a way to disable this feature, even though that capability does not exists (at least consistently) in existing implementations. 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 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. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
