[Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock allen at wirfs-brock.com
Mon May 9 11:14:24 PDT 2011

On May 9, 2011, at 8:38 AM, Tom Van Cutsem wrote:

> Good point. As recently pointed out by Allen, the design point of not allowing proxies to emulate non-configurable properties is still controversial. I have always felt it to be an odd restriction, but I don't have a good alternative that doesn't break |configurable|'s implied invariants. The sweet spot that we seem to be looking for is an API that:
> a) allows non-configurable properties to be emulated,
> b) while still allowing access to these properties to be intercepted (e.g. for logging/tracing),
> c) and upholding the invariants of non-configurable properties.
> The current API doesn't allow a, but upholds c (b is not an issue).
> Your proposed extension would allow a, but not b, and still uphold c.
> If one is willing to drop c, it's easy to get a and b by simply removing the check for configurable:true from the current API.

I contend we should drop c.  A handler that does not maintain the specified invariants is a buggy handler but, in general, we can't guarantee that programs do not contain bugs.  ECMAScript is a language that generally favors expressiveness over early error detection.  More generally, dynamic languages typically defer error checking as late as possible in order to avoid false positives.  They check what a program actually does rather than what it might do.  

Note that there are other explicit or implicit invariants about objects that are not guaranteed.  For example, the keys/enumerate traps should only return the names of properties whose [[enumberable]] attribute is false (at the time of the call) and keys should only return the names of "own" properties.  Yet we don't attempt to enforce that a handler correctly implements these invariants or disable proxy semantics upon the first occurrence of an action that might exercise buggy handler code.

> I can think of an API that satisfies all three by e.g. extending your proposal such that access to non-configurable properties still triggers the get trap, but ignores its result, making the proxy more like a chaperone in Racket <http://docs.racket-lang.org/reference/chaperones.html?q=chaperone#(tech._chaperone)> (chaperones may intercept operations, but are not allowed to influence the result of the operation).
> I'm worried though that such additional magic, tucked away in the proxy implementation, can make for a very difficult-to-understand overall API.
and would also properly result in a higher overhead (and hence less useful) facility.

I think our first priority should be the expressiveness of Proxies.  They need to be able to deal with all the use cases we have discussed including providing an faithful and efficient implementation of the existing built-ins and DOM. After we have that we can try to find situations where we can use the API to enforce various object invariants but even there we need to be selective. After all, a major use case for Proxies is to implement objects that in some way or another violate something about the normal invariants for native ES objects.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110509/9392ac7f/attachment-0001.html>

More information about the es-discuss mailing list