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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
