2011/6/14 Allen Wirfs-Brock <[email protected]> > 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. >
It is true that this strawman would not enable a faithful emulation of the Array "length" property at the meta-level (i.e. when looking at an object as a set of property descriptors). I can't yet judge how much of an issue this is: given the novelty of the property descriptor API, I don't know how much code such an imperfect Array proxy would break. At least at the "base-level" (i.e. regular application code), "length" would be updated as expected, and remains accessible as "arrayproxy.length". (As an aside: re. the emulation of arrays, having a configurable [[Class]] such that |Object.prototype.toString.call(arrayproxy)| can return "[object Array]" seems like a more important imperfection to fix) > 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. > I'm not sure what you mean by special semantics. If you mean strong guarantees/invariants, then one example would be that a non-writable, non-configurable data property is guaranteed to have a stable value. The proposed strawman allows proxies to define such properties, at the expense of giving up interception of access to such a property. Cheers, Tom > 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
