I updated my implementation to fully embrace the "trapping with enforcement" model: all traps on the FixedHandler always forward to the wrapped handler. Some traps will perform consistency checks on the result of the forwarded invocation. Source: <<a href="http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/FixedHandler.js">http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/FixedHandler.js</a>><div>
<div><div><br>In particular, the FixedHandler upholds the following invariants:<br><br>(In what follows, "fixed properties" is a shorthand for "previously exposed non-configurable properties")<br><br>- getOwnPropertyDescriptor cannot report fixed properties as non-existent<br>
- getOwnPropertyDescriptor cannot report incompatible changes to a fixed property (e.g. reporting a non-configurable property as configurable, or reporting a non-configurable, non-writable property as writable)<br>- getPropertyDescriptor: same constraints as for getOwnPropertyDescriptor. Contrary to the "bicephal" model, in the "enforcement" model, getPropertyDescriptor continues to work fine. The proxy still needs to store information about fixed properties of prototype objects, but the proxy as a whole won't misreport such fixed properties as own rather than inherited properties of the proxy.<br>
- defineProperty cannot make incompatible changes to the attributes of fixed properties<br>- defineProperty cannot reject compatible changes made to the attributes of fixed properties<br>- properties returned by the fix() trap are merged with fixed properties, ensuring no incompatible changes can be made when calling freeze, seal, preventExtensions<br>
- delete cannot report a successful deletion of a fixed property<br>- hasOwn cannot report a fixed property as non-existent<br>- has cannot report a fixed property as non-existent<br>- get cannot report inconsistent values for non-writable fixed data properties<br>
- set cannot report a successful assignment for non-writable fixed data properties<br><br>A few more notes about this implementation:<br>- Contrary to the earlier proposed strawman, the defineProperty trap does not need to return a property descriptor anymore, just a boolean success value like delete and set (it previously could return a modified property descriptor so that it could turn data props into accessor props that still triggered the handler. In this updated version, the original handler is always consulted, so the defineProperty trap doesn't need the ability to modify the descriptor.)<br>
<br>- This implementation of the FixedHandler is entirely compatible with the existing ForwardingHandler. The latter doesn't need to be changed at all. If the ForwardingHandler forwards to a regular, well-behaved object, it will never trigger a violation of the above invariants.</div>
<div><br></div><div>- A revoked membrane handler wrapped by a FixedHandler will throw on all operations. No fixed properties are leaked.<br><div><br></div><div>- The strawman wiki page does not yet reflect this implementation. Now that I implemented the enforcement model, I do think it's a pure win as compared to the model currently outlined on the wiki page.</div>
<div><br></div><div>I solicit feedback on the above invariant list: did I miss any? Are some superfluous? Is the cost of checking these acceptable?</div><div><br></div><div>Cheers,</div><div>Tom</div><div><br><div class="gmail_quote">
2011/7/4 Tom Van Cutsem <span dir="ltr"><<a href="http://tomvc.be">tomvc.be</a>@<a href="http://gmail.com">gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">2011/7/3 Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><div class="im">On Sun, Jul 3, 2011 at 11:07 AM, David Bruant <span dir="ltr"><<a href="mailto:david.bruant@labri.fr" target="_blank">david.bruant@labri.fr</a>></span> wrote:<br></div>
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Your code relies on current Proxy implementation behavior (FF4&5)<br>
which doesn't do any check on the "configurable" attribute for<br>
defineProperty and get{Own}PropertyDecsriptor traps<br></blockquote><div><br></div></div></div><div class="im"><div>I didn't know that. Is there a bug filed on this yet or a test case that demonstrates this bug?</div>
</div></div></blockquote><div>
<br></div><div>I knew about FF4&5's behavior, but did not yet submit a bug or include a test case because we did not actually reach consensus on this topic yet. That, in fact, is the whole reason why we are having this discussion on fixed properties :-)</div>

<div><br></div><div>Hopefully, the FixedHandler shows that the changes required to proxies to enforce non-configurability are acceptable, so that proxies can support its behavior by default.</div><div><br></div><div>Cheers,</div>

<div>Tom</div></div>
</blockquote></div><br></div></div></div></div>