get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Tom Van Cutsem at
Wed Feb 20 09:24:12 PST 2013

2013/2/18 Andreas Rossberg <rossberg at>

> On 16 February 2013 20:36, Allen Wirfs-Brock <allen at>
> wrote:
>  > It's to simplify the MOP and that simplification is directly reflected
> as a simplification to the Proxy hander interface. Instead of  6 traps
> (preventExtensions, isExtensible, freeze, isFrozen, seal, isSealed) only
> two are needed.
> >
> > Also, having an explicit frozen object state simplifies some of the
> object invariants which would otherwise perform explicitly specified
> accesses to the target object which would be observable (if the target is
> itself a proxy).
> Well, that is either a breaking change, such that implementations can
> not actually be lazy about it, or it doesn't really remove complexity,
> since you still need to infer the state as a fallback (i.e., it's just
> an optimisation).
> I don't necessarily oppose making that breaking change, but we have to
> be aware that, even though it's an optimisation, the change is yet
> another complication of the object model. The additional state
> modifies the meaning of per-property descriptors on a second level.
> IIUC, defineProperty now has to check against that state, and
> getOwnPropertyDescriptor somehow has to take it into account, too. For
> direct proxies, the respective traps have to extend their validation
> logic. Overall, not a simplification, as far as I can see.

I've been thinking some more about get/setIntegrity and I've come to the
same conclusion. While get/setIntegrity gets rid of 4 traps
(sealed/isSealed/frozen/isFrozen), it does so at the expense of extra
complexity in other parts of the MOP, in particular, adding yet more state
to check and update in [[GetOwnProperty]] and [[DefineOwnProperty]].

Allen, in light of this, wouldn't you agree that it's better to keep the
extra traps?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list