[Harmony Proxies] On property descriptor auto-completion in defineProperty/get{Own}PropertyDescriptor traps (derived from: [Harmony Proxies] Proposal: Property fixing)

Allen Wirfs-Brock allen at wirfs-brock.com
Sun May 8 13:58:26 PDT 2011


I haven't been paying close attention to proxies for a while, so I may be missing something.  However, the requirement that a proxy only has configurable properties seems to severely limit their utility.  

Specify, it means that Proxies can not be used to implement/emulate ES5 Array instances (the length property is non-configurable) and  other built-ins that have non-configurable properties. I thought the ability to do so was one of the original goals of a Harmony Intercession mechanism.

I have also been talking to some DOM implementors who have similar concerns.  The current DOM and the WebIDL/ES DOM bindings apparently have objects with special behaviors where some properties are non-configurable.  How are we going to implement those if Proxies don't allow individual non-configurable properties.

I also have similar concerns about the fix trap: "A non-extensible, sealed or frozen object should somehow restrict the handler’s freedom in terms of what it can return from subsequent calls to ‘set’, ‘get’ etc. For example, if previous invocations of handler.get(p, “foo”) returned a non-undefined value (for some ‘handler’ of a proxy p), then future invocations of handler.get(p, “foo”) should return the same value when p is frozen."  While I can almost rationalize why this might be ok for frozen objects I don't think it flies even there.  I certainly don't see why preventing the addition of new properties or making all properties non-configurable should disable all trapping behavior.  For example, I might want to use a Proxy to log trace accesses to specific properties.  Why should freezing the object block this.

I gather that these constraints were applied  in order to guarantee  certainly invariants about object properties. While these invariants may be important for reasoning about programs it is less clear to me that they are essential for the low level operation of JavaScript implementations.  More importantly, I don't believe that guaranteeing these invariants  is important enough to for Proxies to be unusable for their primary use case of replacing/emulating built-in and host objects.  After all, while ES5 "requires" certain invariants of host objects it doesn't limit host object functionality in an attempt to make violations of those invariants impossible.  I'd be perfectly happy to take the same approach to Proxies.  There are certain invariants that we expect the implementation of a ES object to maintain.  An implementation that doesn't is buggy.  Whether that implementation is expressed in terms of a Proxies, or a "host object" foreign function interface, or the implementation of the core built-in objects is irrelevant.  They all needs equal power or they aren't interchangeable as implementation alternatives.

Allen




More information about the es-discuss mailing list