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

Andreas Rossberg rossberg at google.com
Thu Feb 14 10:46:49 PST 2013

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


More information about the es-discuss mailing list