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

David Bruant david.bruant at labri.fr
Mon Jul 4 13:53:57 PDT 2011

Le 04/07/2011 21:50, Tom Van Cutsem a écrit :
> 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: <http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/FixedHandler.js>
> In particular, the FixedHandler upholds the following invariants:
> (...)
> A few more notes about this implementation:
> - 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.)
And the behavior of returning false (silent reject or throw) depends on
strict of the calling code?

> - 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.
Not only will it never trigger a violation, but it will perfectly
forward both configurable and non-configurable properties (which
required trickery with the "bicephal" model).

> - 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.

> I solicit feedback on the above invariant list: did I miss any? Are
> some superfluous?
I can't think of anything that would be missing or too much on top of my

> Is the cost of checking these acceptable?
To answer this question while keeping the goal of having a consistent
non-configurable properties mechanism, one has to compare with another
alternative that would allow such a mechanism. The only other such
mechanism I've heard of was the bicephal model. In this model, updating
operations (defineProperty, set, delete) would perform exactly the same
invariant checks, so there is no additional cost (besides calling the
traps). However, retrieving operations all require one additional test
(for consistency) and to throw if necessary, (in the bicephal model,
retrieving was "just a lookup"). I find that acceptable.
One additional non-code-related cost is that for any trap considered to
be added to the spec, it will require attention to make sure invariants
can be enforced (hopefully at a small cost).


More information about the es-discuss mailing list