Proposal: Reflecting on non-string property names
allen at wirfs-brock.com
Sun Dec 2 11:28:34 PST 2012
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss