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

Tom Van Cutsem tomvc.be at gmail.com
Wed Jul 13 03:03:39 PDT 2011

I updated <http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>
to reflect our most recent thoughts on how proxies could deal with
non-configurable properties.


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

> 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:
> (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 properties
> - 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,
> preventExtensions
> - 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
> properties
> - set cannot report a successful assignment for non-writable fixed data
> properties
> 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?
> Cheers,
> Tom
> 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/20110713/359502a0/attachment-0001.html>

More information about the es-discuss mailing list