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

Tom Van Cutsem tomvc.be at gmail.com
Mon Jul 4 12:50:40 PDT 2011

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

In particular, the FixedHandler upholds the following invariants:

(In what follows, "fixed properties" is a shorthand for "previously exposed
non-configurable properties")

- getOwnPropertyDescriptor cannot report fixed properties as non-existent
- 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)
- 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.
- defineProperty cannot make incompatible changes to the attributes of fixed
- defineProperty cannot reject compatible changes made to the attributes of
fixed properties
- properties returned by the fix() trap are merged with fixed properties,
ensuring no incompatible changes can be made when calling freeze, seal,
- delete cannot report a successful deletion of a fixed property
- hasOwn cannot report a fixed property as non-existent
- has cannot report a fixed property as non-existent
- get cannot report inconsistent values for non-writable fixed data
- set cannot report a successful assignment for non-writable fixed data

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

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

- A revoked membrane handler wrapped by a FixedHandler will throw on all
operations. No fixed properties are leaked.

- 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? Is the cost of checking these acceptable?


2011/7/4 Tom Van Cutsem <tomvc.be at gmail.com>

> 2011/7/3 Mark S. Miller <erights at google.com>
>> On Sun, Jul 3, 2011 at 11:07 AM, David Bruant <david.bruant at labri.fr>wrote:
>>> - 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
>> I didn't know that. Is there a bug filed on this yet or a test case that
>> demonstrates this bug?
> 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 :-)
> 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.
> Cheers,
> Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110704/f6cb577b/attachment.html>

More information about the es-discuss mailing list