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

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Feb 16 11:36:19 PST 2013

On Feb 14, 2013, at 11:46 AM, Andreas Rossberg wrote:

> On 14 February 2013 01:05, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 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.
> I still must be missing something. Why should the language be changed
> when the proposed change is equivalent anyway? Why is this an
> optimisation that the spec should worry about instead of the
> implementations?

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


More information about the es-discuss mailing list