Feedback on the [[HasProperty]] refactoring
Tom Van Cutsem
tomvc.be at gmail.com
Mon Sep 17 08:05:46 PDT 2012
> In the ES5 world, [[HasOwnProperty]] or "[[GetOwnProperty]]+check if prop
>> !== undefined" is equivalent, but proxies make visible the difference and
>> in the context of the "in" operator, "hasOwn" seems like a more relevant
>> trap to call instead of getOwnPropertydescriptor.
Agreed. And not only is it more natural, it's also way more efficient (the
current algorithm requires a handler to cons a property descriptor, which
requires additional validation as it crosses the proxy boundary, only to
immediately throw it away)
I forgot to add that since the has trap is a proto-climbing, it may be
> worth adding receiver as last trap argument, like get and set. Otherwise,
> when the has trap is called with the proxy as prototype of another object,
> the trap is missing some context if it doesn't have the receiver.
Well, the in-operator, unlike property get/set, is currently not
this-sensitive. Why give up on that? Besides, from a capability POV, it
would mean that |lhs in rhs| would grant rhs access to lhs where that
currently isn't the case. Not that code depends on this, but why introduce
the "leak" if the semantics doesn't require it. I'd argue for the status
quo in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss