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

Allen Wirfs-Brock allen at
Mon Nov 12 13:56:53 PST 2012

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.

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.   In C++ this might be expressed as two overloads for GetOwnProperty:

PropertyDescriptor*  HasOwnProperty(name k) {...}

bool HasOwnProperty(name k, bool needDescriptor) (...)


> /be

More information about the es-discuss mailing list