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

Tom Van Cutsem at
Mon Nov 12 13:02:21 PST 2012

2012/11/12 Allen Wirfs-Brock <allen at>

> On Nov 12, 2012, at 2:21 AM, Brandon Benvie wrote:
> > Shouldn't it be the reverse, based on the removal of
> getPropertyDescriptor/Names? The proxy controls what i's [[Prototype]] is
> which indirectly directs how non-own lookups proceed. The functionality of
> `has` can (and usually should) be derived from proto-walking hasOwn until
> true or null.
> yes, that would be a good fix for this particular problem.
>  [[HasOwnProperty]] could remain as an internal method and HasProperty
> could be defined as an abstraction operation that uses the [[Prototype]]
> internal accessor and [[HasOwnProperty]].

I also like it. So this implies that we keep "hasOwn", get rid of the "has"
trap, and that |name in proxy| triggers the proxy's hasOwn() trap. If that
trap returns false, the proxy's |getPrototypeOf| trap is called and the
search continues.

> 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).

Maybe I just need to get used to the fused trap signatures. I'll try to
experiment by writing some code using such an API.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list