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

Allen Wirfs-Brock allen at
Sun Nov 11 17:17:07 PST 2012

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

Given,that [[HasOwnProperty]] is not really essential, has good alternatives,  and exposes the potential for such inconsistency I think we should just eliminate it.  Does anyone want to argue that we need to keep it?

(of course, this isn't the only situation where a proxy can be defined that exhibits inconsistent responses for the internal methods.  I'm thinking about some others too, but this one seems fairly straightforward to eliminate).


More information about the es-discuss mailing list