The ES6 MOP (Was: New ES6 draft now available)
bruant.d at gmail.com
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 wirfs-brock.com
>> <mailto:allen at wirfs-brock.com>>
>> I see that  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  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  makes it to any version of ES6, it
will be the way to explain the difference.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss