[Harmony proxies] Non-configurable properties: fixed properties VS trap all with invariants enforcement

Tom Van Cutsem tomvc.be at gmail.com
Mon Jul 4 01:53:38 PDT 2011

2011/7/3 David Bruant <david.bruant at labri.fr>

> Just to make sure I do not misunderstand your work:
> - Your code relies on current Proxy implementation behavior (FF4&5)
> which doesn't do any check on the "configurable" attribute for
> defineProperty and get{Own}PropertyDecsriptor traps

Correct. I forgot to mention that I tested this code in Firefox 5.0.

> - The idea is that eventually, by default, any handler would become your
> wrapped FixedHandler() handler (functionnally, of course; exact
> implementation would be left at the discretion of implementors)

Yes, at least, if we can come to agree upon its need and whether the
overhead is deemed acceptable.
For now, FixedHandler.js defines a method "installAsDefault" that replaces
the built-in Proxy.create and Proxy.createFunction with functions that
always wrap their handler. If Proxy were to be frozen after this change, it
would enforce fixed handlers on subsequent scripts.

> In your current FixedHandler implementation, all traps of the wrapped
> handler are called for configurable properties. For non-configurable
> properties, if already present in this.fixedProps, the "delete",
> "hasOwn", "has", "get" and "set" traps aren't called while all others
> are (first instruction of all other traps).
> This might appear to be an inconsistent behavior to the user. An easy
> fix could be to change a little bit these traps:

<Tom: removed implementation of the traps>
> This way, all traps are called, regardless of configurability and the
> invariant-complying result is returned in all cases.

That would indeed be more consistent, and would allow e.g. revoked membranes
to throw on all operations, regardless of whether the accessed property is

> When it comes to return value, my implementation may surprise the
> programmer as what he return from his (target)handler doesn't match what
> is returned in the end. An alternative could be to test if "ret" matches
> expectations (with harmony:egal, not === of course) and throw if it's
> not the case.

Yes, I think such a check would be appropriate. In a sense, a trap returning
a different value for a {writable:false, configurable: false} property is as
much a violation of the spec. as the getOwnPropertyDescriptor trap reporting
said property as {configurable: true}.

> Unless testing expectation matching, there is barely any overhead in
> calling the traps (besides the trap themselves, but that's a cost the
> programmer is ready to pay for configurable properties already) when
> comparing with your implementation.
> And it has the advantages of not leaking things the way I've showed it
> at the beginning of this thread for the membrane use case.

Yes. This prototype implementation, because it continues to forward most
operations to its wrapped handler even for fixed properties, is much closer
to what you called the "enforcement" model than to the earlier "bicephal"

The enforcement turned out to be relatively easy to program in JS itself
thanks to the behavior of Object.defineProperty and Object.defineProperties
(succeed silently when consistent changes are made, throw otherwise).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110704/e32427d7/attachment.html>

More information about the es-discuss mailing list