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

Tom Van Cutsem tomvc.be at gmail.com
Tue Jul 5 02:53:54 PDT 2011

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

> Le 04/07/2011 21:50, Tom Van Cutsem a écrit :
> > 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?

Yes, that would be the idea, by analogy with 'set' and 'delete'.

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

Yes. The enforcement model does not introduce any additional work for
handlers that emulate or wrap an ES5-conformant object.

They only require the handler writer to pay more attention when the handler
is emulating/forwarding to, say, a non-conformant host object. But at that
point, presumably, the job of the proxy is to "tame" that host object and to
intentionally restore ES invariants, so the additional complexity required
to pass all checks is then an explicit goal rather than a nuisance.

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

Forgot to mention it earlier: thanks David for your constructive feedback.
Iteration is good!

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

More information about the es-discuss mailing list