Feedback on the [[HasProperty]] refactoring

[David Bruant]

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