Discuss
  • Feedback on the [[HasProperty]] refactoring

Feedback on the [[HasProperty]] refactoring

# David Bruant (13 years ago)

I'm talking about 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 Bruant (13 years ago)

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 :

# Tom Van Cutsem (13 years ago)

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.

Agreed. And not only is it more natural, it's also way more efficient (the current algorithm requires a handler to cons a property descriptor, which requires additional validation as it crosses the proxy boundary, only to immediately throw it away)

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.

Well, the in-operator, unlike property get/set, is currently not this-sensitive. Why give up on that? Besides, from a capability POV, it would mean that |lhs in rhs| would grant rhs access to lhs where that currently isn't the case. Not that code depends on this, but why introduce the "leak" if the semantics doesn't require it. I'd argue for the status quo in this case.

# Tom Van Cutsem (13 years ago)

For the record, I updated the [[HasProperty]] algorithm on the wiki to call [[HasOwnProperty]] instead of [[GetOwnProperty]], as suggested.

2012/9/17 Tom Van Cutsem <tomvc.be at gmail.com>