I forgot to add that since the has trap is a proto-climbing, it may be
worth adding receiver as last trap argument, like get and set.
Otherwise, when the has trap is called with the proxy as prototype of
another object, the trap is missing some context if it doesn't have the
receiver.
Le 17/09/2012 16:38, David Bruant a écrit :
Hi,
I'm talking about
http://wiki.ecmascript.org/doku.php?id=harmony:proto_climbing_refactoring#refactoring_hasproperty
The 2 first steps of the proposed algorithms are:
1. Let prop be the result of calling the [[GetOwnProperty]] internal
method of O with property name P.
2. If prop is not undefined, return true.
If O is a proxy, it means that the getOwnPropertyDescriptor trap is
being called. This sounds a bit silly considering handlers have an
"hasOwn" trap which is what could be expected to be called.
It would turn the [[HasProperty]] algorithm to the more elegant:
1. Let hasOwn be the result of calling the [[HasOwnProperty]] internal
method of O with property name P.
2. If hasOwn is true return true.
3. Let proto be the [[Prototype]] internal property of O.
4. If proto is null, return false
5. Return the result of calling the [[HasProperty]] internal method of
proto with argument P.
In the ES5 world, [[HasOwnProperty]] or "[[GetOwnProperty]]+check if
prop !== undefined" is equivalent, but proxies make visible the
difference and in the context of the "in" operator, "hasOwn" seems
like a more relevant trap to call instead of getOwnPropertydescriptor.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
