getPrototypeOf invariant

David Bruant bruant.d at gmail.com
Thu Oct 4 08:40:38 PDT 2012


2012/10/4 Mark S. Miller <erights at google.com>

>
> On Thu, Oct 4, 2012 at 4:36 AM, David Bruant <bruant.d at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121004/62aec402/attachment.html>


More information about the es-discuss mailing list