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 <[email protected]> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
