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
> Another potential consistency issue is between [[HasOwnProperty]] and
> [[GetOwnProperty]]. That could be eliminated by combining them into one
> [[GetOwnPropety]](name, descriptorNeeded) -> descriptor | boolean |
> 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...
More information about the es-discuss