getPrototypeOf invariant

David Bruant bruant.d at gmail.com
Thu Oct 4 12:55:42 PDT 2012


Le 04/10/2012 20:35, Mark S. Miller a écrit :
> On Thu, Oct 4, 2012 at 8:40 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121004/d719007b/attachment-0001.html>


More information about the es-discuss mailing list