Doesn't this new proposal still preclude using proxies to create an exact emulation of the built-in Array object type. The "length" property of arrays is specified to be non-configurable yet special behavior must occur each time the value of length is changed. The proposal would allow "length" to be "fixed" as an accessor property whose set behavior did the necessary processing. However, that is also a violation of the Array specification as it requires that "length" exhibit the attributes of a data property.
I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects. I really don't know where this idea that non-configurable implies no special semantics comes from. That isn't the case in the ES5 specification (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties. Allen On Jun 14, 2011, at 1:57 AM, Tom Van Cutsem wrote: > Hi, > > To address the outstanding issue of how proxies should deal with > non-configurable properties, I picked up on Sean's earlier proposal, adapted > it and turned it into a strawman: > <http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>. > > My adaptation is more permissive than the original proposal in that it still > allows proxies to intercept access to non-configurable properties if they are > willing to expose them as accessor rather than data properties. > > This proposal would allow proxies to cover more use cases (because they can > now emulate non-configurable properties), at the expense of additional > complexity within proxy objects. > > As always, discussion and feedback are appreciated. > > Cheers, > Tom > > 2011/5/4 Sean Eagan <[email protected]> > What: > > Honor attempts to make individual proxy properties non-configurable. > > Why: > > For consistency since attempts to make *all* of a proxy's properties > non-configurable are honored via the "fix" trap. > > Example: > > var x = Proxy.create({ > defineProperty: function() {}, > getPropertyDescriptor: function() { > return { > value: "whatever I want", > writable: true, > configurable: true, > enumerable: false > }; > } > }); > Object.defineProperty(x, "foo", {value: "bar", configurable: false, > writable: false, enumerable: true}; > > /* ... */ > > // logs "whatever I want", not "bar" > console.log(x.foo); > // non-writable, but doesn't throw > object.foo = "baz"; > // non-configurable, but doesn't throw > Object.defineProperty(x, "foo", {configurable: true}); > > How: > > Assume a "defineProperty" trap invocation due to > |Object.defineProperty(proxy, name, pd)| where |!pd.configurable|. If > return value is... > > true - Henceforth bypass |proxy|'s handler for any traps with a > property name parameter when the property name would be |name| > false - throw TypeError similarly to "fix" trap > > Update the "fix" trap semantics such that when its return value is not > undefined but rather a property descriptor map, behavior is similar to > |Object.defineProperties| in that improperly redefining any properties > will cause a TypeError to be thrown. > > Notes: > > Can check |Object.getOwnPropertyDescriptor(proxy, name).configurable| > to determine if a given proxy property is fixed since it will always > be false in this case. > > > Thanks, > Sean Eagan > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
