getPrototypeOf invariant
Hi, Currently, the wiki says: Invariant check: check whether the target’s prototype and the trap result are identical. If the trap can only report one value, there is almost no point in having a trap. A getPrototypeOf trap allows for proxies to potentially simulate __proto__ in a platform where it wouldn't exist natively. It only does if it's possible to freely report any Object (as per ES5.1 - 8.6) or null. Or maybe what was meant was only when the target is non-extensible? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: getPrototypeOf invariant
On Thu, Oct 4, 2012 at 4:36 AM, David Bruant bruan...@gmail.com wrote: Hi, Currently, the wiki says: Invariant check: check whether the target’s prototype and the trap result are identical. If the trap can only report one value, there is almost no point in having a trap. General principle: even when the successful result of the trap must be identical to that same operation as performed on the target, making it a trap has two uses and a corresponding hazard: * It allows the operation to be aborted by throwing an exception. * It allows the target to be modified first, in anticipation of the target being queried at the end of the trap. The hazard which is necessarily implied by these is that it allows interleaving of user code within an operation that would otherwise have been safe against interleaving. That's one of the reasons why we don't trap everything with this identical feature, for example, === and typeof. A getPrototypeOf trap allows for proxies to potentially simulate __proto__ in a platform where it wouldn't exist natively. It only does if it's possible to freely report any Object (as per ES5.1 - 8.6) or null. Or maybe what was meant was only when the target is non-extensible? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: getPrototypeOf invariant
2012/10/4 Mark S. Miller erig...@google.com On Thu, Oct 4, 2012 at 4:36 AM, David Bruant bruan...@gmail.com wrote: Hi, Currently, the wiki says: Invariant check: check whether the target’s prototype and the trap result are identical. If the trap can only report one value, there is almost no point in having a trap. General principle: even when the successful result of the trap must be identical to that same operation as performed on the target, making it a trap has two uses and a corresponding hazard: * It allows the operation to be aborted by throwing an exception. At a time getPrototypeOf wasn't a trap, it was not really an expected feature. * It allows the target to be modified first, in anticipation of the target being queried at the end of the trap. Do we really need to change the target prototype before reporting a different prototype? IIRC for performance reasons, it's been decided to not perform any inheritance-related invariant check, so which object is in the prototype or reported as such does not really matter since it provides no guarantee for set/get/has traps. For these traps, any lie can be told for not-own properties. In that context, being forced to return a given prototype is a bit too much in my opinion since it's not an information client code can really rely on for anything Things are a bit different for non-extensible objects from which we can have stronger expectations (since setting __proto__ doesn't work for them) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: getPrototypeOf invariant
Le 04/10/2012 20:35, Mark S. Miller a écrit : On Thu, Oct 4, 2012 at 8:40 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: * It allows the target to be modified first, in anticipation of the target being queried at the end of the trap. Do we really need to change the target prototype before reporting a different prototype? IIRC for performance reasons, it's been decided to not perform any inheritance-related invariant check, so which object is in the prototype or reported as such does not really matter since it provides no guarantee for set/get/has traps. For these traps, any lie can be told for not-own properties. In that context, being forced to return a given prototype is a bit too much in my opinion since it's not an information client code can really rely on for anything Things are a bit different for non-extensible objects from which we can have stronger expectations (since setting __proto__ doesn't work for them) That last is really the point. It enforces that a proxy cannot appear to change its __proto__ unless it really can change the __proto__ of its target. Besides non-extensibility, another reason it may not be able to is that the relevant Object.prototype.__proto__ was deleted and the proxy's handler has no access to its original value. I'm not sure I understand your answer. Should the invariant stand even for extensible proxies? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: getPrototypeOf invariant
If the extensible proxy has no access to the original Object.prototype.__proto__, then it cannot modify the [[Prototype]] of its target, and so should not be able to seem to have its own mutable [[Prototype]] On Thu, Oct 4, 2012 at 12:55 PM, David Bruant bruan...@gmail.com wrote: Le 04/10/2012 20:35, Mark S. Miller a écrit : On Thu, Oct 4, 2012 at 8:40 AM, David Bruant bruan...@gmail.com wrote: * It allows the target to be modified first, in anticipation of the target being queried at the end of the trap. Do we really need to change the target prototype before reporting a different prototype? IIRC for performance reasons, it's been decided to not perform any inheritance-related invariant check, so which object is in the prototype or reported as such does not really matter since it provides no guarantee for set/get/has traps. For these traps, any lie can be told for not-own properties. In that context, being forced to return a given prototype is a bit too much in my opinion since it's not an information client code can really rely on for anything Things are a bit different for non-extensible objects from which we can have stronger expectations (since setting __proto__ doesn't work for them) That last is really the point. It enforces that a proxy cannot appear to change its __proto__ unless it really can change the __proto__ of its target. Besides non-extensibility, another reason it may not be able to is that the relevant Object.prototype.__proto__ was deleted and the proxy's handler has no access to its original value. I'm not sure I understand your answer. Should the invariant stand even for extensible proxies? David -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: getPrototypeOf invariant
Le 04/10/2012 22:01, Mark S. Miller a écrit : If the extensible proxy has no access to the original Object.prototype.__proto__, then it cannot modify the [[Prototype]] of its target, and so should not be able to seem to have its own mutable [[Prototype]] Ok, so the rationale behind the invariant is: You can report a different prototype only if you're able to modify it on the target. And it makes a lot of sense indeed. Sorry it took me about 3 round-trips to understand this :-s David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: getPrototypeOf invariant
David Bruant wrote: Le 04/10/2012 22:01, Mark S. Miller a écrit : If the extensible proxy has no access to the original Object.prototype.__proto__, then it cannot modify the [[Prototype]] of its target, and so should not be able to seem to have its own mutable [[Prototype]] Ok, so the rationale behind the invariant is: You can report a different prototype only if you're able to modify it on the target. And it makes a lot of sense indeed. Sorry it took me about 3 round-trips to understand this :-s That's the beauty of 'delete Object.prototype.__proto__'! ;-) /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
