On Dec 2, 2012, at 11:16 AM, Tom Van Cutsem wrote: > > Right. Enumeration has weird invariants because of the complex state-space of > JS object invariants. For frozen objects, the invariants become relatively > easy to check (as you say: check if each enumerated key is an own property of > target, and count whether the total number of generated keys equals the total > amount of own properties of the target). For non-frozen objects, things are > more complicated. > > Are you suggesting that we only enforce invariants if the proxy/target are > really frozen at the start of enumeration, and give up on invariants in all > other cases? I think this would be sufficient for most practical use cases, > but it would be the first time that we visibly treat "frozen" objects > specially (all other invariants are expressed only in terms of > non-extensibility or non-configurability of individual properties) >
Yes. This goes along with the idea of a SetIntegrity internal method/trap that makes non-extensible/sealed/frozen real object states rather than the last two being derived from property inspection. I think have those states at the object level would simplify the specification of invariants (as well as eliminate many uses of observable property level operation in the validation of the invariants) Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
