Feedback on the [[HasProperty]] refactoring

[Tom Van Cutsem]

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.
>
> Cheers,
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120919/ecdca770/attachment.html>