<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 15, 2011, at 12:38 PM, Allen Wirfs-Brock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 15, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>But can't a Proxy based object do all sorts of nasty back channel stuff even while it maintains the apparent object freeze invariants?</div></div></div></blockquote><div><br></div><div>Duh, of course a frozen object really isn't a Proxy any more as currently defined. But is has also lost all useful intercession  derived semantics.</div></div></div></blockquote><div><br></div>This may be ok, so long as we can distinguish preventExtensions from seal from freeze, *and* determine the class or constructor used for the newborn object that becomes the proxy. Yes, I'm thinking faithful Array emulation.</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>BTW, if <a href="http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties">http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties</a> was extended to support Object.preventExtensions we might not have anything to argue about except perhaps performance issues. </div></div></div></blockquote><br></div><div>Indeed, that helps quite a bit. Glad to hear it.</div><div><br></div><div>But there may be more power needed in the fix trap, per the above Array-proxy test.</div><div><br></div><div>/be</div></body></html>