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

Brendan Eich brendan at
Mon Nov 12 13:59:50 PST 2012

Allen Wirfs-Brock wrote:
> On Nov 12, 2012, at 1:20 PM, Brendan Eich wrote:
>> Tom Van Cutsem wrote:
>>>     Another potential consistency issue is between [[HasOwnProperty]]
>>>     and [[GetOwnProperty]].  That could be eliminated by combining
>>>     them into one operation:
>>>     [[GetOwnPropety]](name, descriptorNeeded) ->  descriptor | boolean
>>>     | undefined
>>>     If descriptorNeeded is true it acts as the current
>>>     [[GetOwnProperty]]. If descriptorNeeded is false it acts as the
>>>     current [[HasOwnProperty]].
>>>     At the handler-level it makes it impossible to override
>>>     "hasOwn"without also overriding "getOwnPropertyDescriptor"
>>> I understand the goals, but I'm not a big fan of fusing traps like this. It trades complexity on one level (inconsistencies between traps) for complexity on another level (if-tests in fused trap bodies to determine what type of value to return).
>> Agreed. That kind of return value overloading has a smell.
> Yes it does!  But allowing separate inconsistent implementations of [[HasOwnProperty]] and [[GetOwnProperty]]  enables the creation a big mess that may spell even worse.

Spelling aside, it smells better to me.

> Particularly, in this case where [[HasOwnProperty]] adds nothing essential as [[HasOwnProperty]] should always be equivalent the ToBoolean of the result of [[GetOwnProperty]].  It is really just an optimization to avoid reifying a descriptor in cases where it isn't needed.   From that perspective, a parameter that advises whether or a descriptor is needed does seem too smelly.

"does not"?

>     In C++ this might be expressed as two overloads for GetOwnProperty:
> PropertyDescriptor*  HasOwnProperty(name k) {...}
> bool HasOwnProperty(name k, bool needDescriptor) (...)

Sorry, this is JS not C++ and even in C++ flag parameters are considered 
a smell in many style guides.

We now have over two years experience with derived and fundamental traps 
in Firefox's proxy implementation, and the hazard of inconsistent traps 
is minor from what I can see. Cc'ing jorendorff for his view.


More information about the es-discuss mailing list