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:
>> 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
> * 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
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss