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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
