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
