The ES6 MOP (Was: New ES6 draft now available)

David Bruant bruant.d at
Mon Nov 26 10:49:09 PST 2012

Le 26/11/2012 19:37, Allen Wirfs-Brock a écrit :
> On Nov 26, 2012, at 10:00 AM, Tom Van Cutsem wrote:
>> 2012/11/24 Allen Wirfs-Brock <allen at 
>> <mailto:allen at>>
>>     I see that [2] call for filtering __proto__ access in Get/Put
>>     handlers.   I think that dealing with it in a Get/SetInheritance
>>     handler would be a much more efficient way to hand this extremely
>>     rare operation.  Rather than filtering for it on every property
>>     access, an handler that cares only needs to worry about the
>>     actual Get/SetInhertiance.
>> Hmm, so you're arguing that proxy.__proto__ would be equivalent to 
>> Object.getPrototypeOf(proxy), and trigger the "getPrototypeOf" trap, 
>> rather than triggering the "get" trap?
>> I guess that more accurately reflects the magical behavior of __proto__.
>> Paradoxically, this will move the filter check into the proxy 
>> implementation itself, to properly intercept proxy["__proto__"]. On 
>> first sight, this seems to introduce more overhead.
> We need to pin down exactly what backwards compatible semantics of 
> "__proto__" we need to provide.
> My preference would be to recognize  expr.__proto__ as a syntactic 
> form with its own runtime semantics.  That would exclude things like 
> expr["__proto__"] and I'd be quite happy with that if it does have any 
> real world compat issue.
The decoupling of [] and property access [1] could take care of 
What I mean by that is that the spec for __proto__ can be as it is now 
and could separate both forms. If [1] makes it to any version of ES6, it 
will be the way to explain the difference.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list