oliver at apple.com
Fri Feb 10 14:48:32 PST 2012
On Feb 10, 2012, at 2:29 PM, Brendan Eich wrote:
> 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 only rules we have in JSC wrt syntactic identification of __proto__ are to prevent people from naming functions __proto__ :D
>> 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.
Indeed, if we switched to any value on the Object prototype for __proto__ we'd need to special case it in JSC (presumably spider monkey already does) actually JSC already specialises, purely to allow __proto__ to work in literals :D
More information about the es-discuss