iterate and enumerate trap signature inconsistency

Mark S. Miller erights at google.com
Wed Sep 12 09:11:49 PDT 2012


On Wed, Sep 12, 2012 at 1:27 AM, David Bruant <bruant.d at gmail.com> wrote:

>  [...] There are numerous examples where ES5 assumptions are questioned
> by proxies, like:
>
>     for(var p in obj){
>         var desc = Object.getOwnPropertyDescriptor(obj, p)
>         // ...
>     }
>
> In this snippet, ES5 semantics guarantees that desc will be an object at
> every iteration. Proxies challenge this assumption (because of the
> enumerate trap, but also the combination between the enumerate and
> getOwnPropertyDescriptor trap). But as Mark said, there is a trade-off to
> be found. [...]
>

The most important ES5 guarantee waived by proxies is when interleaving of
code from accessed object can occur.
Assuming Object.getOwnPropertyDescriptor is the
original Object.getOwnPropertyDescriptor, in the code above, no code from p
can interleave in the above actions. Proxies waive this many places,
including in this example. This has been the biggest newly introduced
hazard, and we've tried to make tasteful choices about where this can and
cannot occur.

However, given this newly introduced interleaving hazard, your example does
not demonstrate a further weakening of invariants. This is the "momentary
invariant" vs "eternal invariant" issue explained at <
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html>. It is
also why Tom's message mentions "*non-configurable* enumerable [own]
properties of the target". The fact that they are enumerated is an eternal
invariant.

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120912/ae6f519b/attachment.html>


More information about the es-discuss mailing list