tomvc said:
8.5.14 Proxy [[Freeze]]
8.5.15 Proxy [[Seal]]
8.5.16 Proxy [[IsFrozen]]
8.5.17 Proxy [[IsSealed]]
I think I'm ready to give up on all of these (and so drop these methods from the internal MOP and the Reflect module altogether).
(although I don't agree with your Comment[56-57-58] that keeping them would entail a lot of additional invariant checks: the checks are still there even without these internal methods, they're just performed implicitly by the Object.freeze algorithm when it loops over all the properties and calls [[DefineOwnProperty]] for each property)
------
In terms of rev 14, we could revert [[HasIntegrity]]/[[SetIntegrity]] back to [[IsExtensible]]/[[PreventExtensions]]
I just had a look at the Rev14 draft.
In this draft, since Object.defineProperty does not actually check or set the integrity level, Object.isFrozen is changed in a backwards-incompatible way as discussed on es-discuss: <https://mail.mozilla.org/pipermail/es-discuss/2013-February/028854.html>
Is the plan really to proceed down this path? From your comment, it seems like the change might be reverted.
In any case, do you feel that the simplification of consolidating freeze/seal/preventExtensions is really worth the backwards-incompatible change? I feel like it is not. In addition, this change breaks the 1-to-1 correspondence between internal methods and user-facing APIs (on Object, Proxy handlers and Reflect).
I withdraw my earlier comment. I now understand where you want to go with this. I agree with moving back to [[IsExtensible]]/[[PreventExtensions]] MOP methods.
fixed in rev16 editor's draft
fixed in rev16 draft. July 15, 2013