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

Tom Van Cutsem tomvc.be at gmail.com
Mon Nov 12 13:02:21 PST 2012


2012/11/12 Allen Wirfs-Brock <allen at wirfs-brock.com>

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

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121112/e873f09f/attachment.html>


More information about the es-discuss mailing list