A case for removing the seal/freeze/isSealed/isFrozen traps

[Tom Van Cutsem]

2013/2/14 Allen Wirfs-Brock <allen at wirfs-brock.com>

>
> On Feb 13, 2013, at 12:53 PM, David Bruant wrote:
>
>  Interesting.
>
> So what would happen when calling Object.isFrozen on a proxy? Would
> Object.isFrozen/isSealed/isExtensible reach out directly to the target? or
> a unique "state" trap returning a string for all of them? ("state" is too
> generic of a name, but you get the idea)
>
>
> This is a question regarding proxy design, rather than the MOP. Either
> get/setIntegrity traps to the handler or it forwards directly to the
> target.  That's would be a design issue for Tom, but my starting point is
> to simply follow the current design decisions made for
> [[PreventExtensions]]/[[IsExtensible]]
>

A get/setIntegrity trap with the invariant constraints of
isExtensible/preventExtensions would be the obvious path to take.

One thing that remains unclear to me: if the state of an object becomes
explicit, we introduce the risk for this state to become inconsistent with
the state from which it is derived.

For example, setting the integrity of an object to "frozen" must still make
all own properties non-configurable, i.e.

Reflect.setIntegrity(obj, "frozen")

should have the same effect as

Object.freeze(obj)

Likewise, turning the last configurable property of a non-extensible object
into a non-configurable property should automagically change the state to
"frozen", i.e.

Object.defineProperty(obj, "lastProperty", { configurable: false }) // must
update internal state as well as the property
Reflect.getIntegrity(obj) === "frozen"

Will this not just shift the current complexity someplace else?

>
> Regardless on the final decision on (full) notification proxies, maybe
> these operations (isSealed/isFrozen) could have notification trap. The
> invariant is that the answer has to be the target one (all the time), so
> the trap return value is irrelevant. Like the getPrototypeOf trap.
>
>
> Right, one way or another these operations need to be part of the MOP.
>

If we go for get/setIntegrity I wouldn't re-introduce all the derived
operations as notification traps. Then we might as well leave things the
way they are.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130214/2a2d5d55/attachment.html>