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.
Cheers, Tom 2011/7/4 Tom Van Cutsem <[email protected]> > 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 <[email protected]> > >> 2011/7/3 Mark S. Miller <[email protected]> >> >>> On Sun, Jul 3, 2011 at 11:07 AM, David Bruant <[email protected]>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 >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
