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

[Allen Wirfs-Brock]

On Feb 13, 2013, at 12:53 PM, David Bruant wrote:

> Le 13/02/2013 20:36, Tom Van Cutsem a écrit :
>> Hi David,
>> 
>> I went a bit too far suggesting frozen objects could de-facto disappear with proxies.
>> I'm still unclear on the need for specific seal/freeze/isSealed/isFrozen traps
>> 
>> I think Allen and I reached consensus that we might do without those traps.
> Excellent!

Where "do without", means replaced with  set/getIntegrity traps and objects have explicit internal state whose value is one of normal/non-extensible/sealed/frozen  (and possibly)  "fixed-inheritance" between normal and non-extensible to freeze [[Prototype]]).

[[SetIntegrity]] can increase the integrity level but not decrease it. 

The perf and invariant complexity concerns come from the fact that the sealed/frozen status of an object can only be inferred by inspecting all of its methods. Having an explicit state eliminates the need to do this inspection.  It also simplifies the MOP by merging all of the extensible/sealed/frozen related MOP operations into only two ops.  But, one way or another, these object state transitions must be accounted for in the MOP.

For this to fly, implementation have to be able to expand their current 1 bit of of extensible state to at least 2 bits (3 would be better).  Or perhaps not, I suppose we could just introduce the MOP level changes and a lazy implementation could continue to infer the state by examining all its methods.



> 
>> In addition, Allen was considering an alternative design where the "state" of an object (i.e. "extensible", "non-extensible", "sealed" or "frozen") is represented explicitly as an internal property, so that Object.isFrozen and Object.isSealed must not "derive" the state of an object from its properties.
> 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]]

> 
> 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.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130213/6685b215/attachment-0001.html>