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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
