Re: Feedback on the [[HasProperty]] refactoring
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...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Feedback on the [[HasProperty]] refactoring
Hi, I'm talking about http://wiki.ecmascript.org/doku.php?id=harmony:proto_climbing_refactoring#refactoring_hasproperty The 2 first steps of the proposed algorithms are: 1. Let prop be the result of calling the [[GetOwnProperty]] internal method of O with property name P. 2. If prop is not undefined, return true. If O is a proxy, it means that the getOwnPropertyDescriptor trap is being called. This sounds a bit silly considering handlers have an hasOwn trap which is what could be expected to be called. It would turn the [[HasProperty]] algorithm to the more elegant: 1. Let hasOwn be the result of calling the [[HasOwnProperty]] internal method of O with property name P. 2. If hasOwn is true return true. 3. Let proto be the [[Prototype]] internal property of O. 4. If proto is null, return false 5. Return the result of calling the [[HasProperty]] internal method of proto with argument P. 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. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Feedback on the [[HasProperty]] refactoring
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
