Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

Andreas Rossberg rossberg at
Mon Nov 12 02:14:05 PST 2012

On 12 November 2012 02:17, Allen Wirfs-Brock <allen at> wrote:
> It isn't clear to me why the [[HasOwnProperty]] internal method and the hasOwn Proxy trap need to exist as object behavior extension points.
> Within my current ES6 draft, [[HasOwnProperty]] is only used within the definition of the ordinary [[HasProperty]] internal method and in the definition of Object.prototype.hasOwnProperty.
> The first usage, could be replaced by an inline non-polymorphic property existence check while the latter could be replaced by a [[GetOwnProperty]] call with a check for an undefined result.
> The existence of both [[HasOwnProperty]] and [[HasProperty]] creates the possibility of object that exhibit inconsistent results for the two operations.  A reasonable expectation would seem to be:
> If O.[[HasProperty]](K) is false, then O.[[HasOwnProperty]](K) should also be false.
> This is in fact the case for all ordinary objects that only have ordinary object  in their inheritance chain. Now consider a proxy defined like so:
> let p = new Proxy({}, {
>    hasOwn(target,key) {return key === 'foo' ? false: Reflect.hasOwn(target,key)}
>    has(target,key) {return key === 'foo' ? true: Reflect.has(target,key)}
> });
> console.log(Reflect.hasOwn(p,"foo"));  //will display: false
> console.log(Reflect.has(p,"foo"));          //will display: true

Well, this is only one such example, there are plenty of similar ways
to screw up the object model with proxies. For example, there is no
guarantee that the has, get, getOwnProperty{Descriptor,Names} traps
behave consistently either. When you buy into proxies, you have to buy
into that as well.

Nevertheless, I agree that [[HasOwnProperty]] and the hasOwn trap are
dispensable, but do not feel strongly about it. Just looking at the
traps from a programmer POV, it may feel a bit asymmetric to have
hasOwn but not e.g. getOwn (although I know where the difference is
coming from).


More information about the es-discuss mailing list