Feedback on the [[HasProperty]] refactoring
Tom Van Cutsem
tomvc.be at gmail.com
Wed Sep 19 00:44:32 PDT 2012
For the record, I updated the [[HasProperty]] algorithm on the wiki to call
[[HasOwnProperty]] instead of [[GetOwnProperty]], as suggested.
2012/9/17 Tom Van Cutsem <tomvc.be at gmail.com>
> Hi David,
>> 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