Hi Sean, So in this proposal, once an individual property has been fixed, any access/assignment to it can no longer be intercepted? I'm not sure whether that's always beneficial. We are then taking away some power of proxies to ensure more consistency, but maybe this additional power is still needed in some wrapping scenarios. Consider a hypothetical scenario in which a funky host object ignores the "configurable" attribute. Proxies won't be able to patch it up anymore. (I have no idea how likely such scenarios actually are though)
Also, as you point out, full consistency across all traps is difficult to guarantee, so does it make sense to enforce consistency for some traps but not for others? The overall behavior of the proxy may still be inconsistent. I do see benefit in this proposal as an aid for proxy writers to develop more well-behaved proxies. But for that purpose it seems that this proposal can be fully written as a Javascript library layered on top of the existing API. Cheers, Tom 2011/5/5 Sean Eagan <[email protected]> > Further clarification: > > The traps that have a property name parameter are... > > getOwnPropertyDescriptor > hasOwn > defineProperty > delete > getPropertyDescriptor > has > get > set > > The internal methods that these traps are invoked from could delegate > to their standard object implementations if the property name they are > passed represents a fixed property, and perform proxy logic otherwise. > > It would be optimal to ensure that all the other traps ... > > getOwnPropertyNames > keys > getPropertyNames > enumerate > iterate > > ... always include any fixed properties, but the associated validation > logic would be inefficient, and a solution along the lines of just > tacking the fixed properties on to the front is probably too > inflexible, so it is probably leave those traps alone with respect to > property fixing. > > Implementation considerations: > > Implementations could store fixed properties in an own properties > table just as they would for regular objects. This table would not > need to be created unless and until any properties are actually fixed. > When a proxy's "fix" trap is invoked, if this table already exists, > it just "becomes" the object's own property table, and then the > properties in the "fix" trap return value can be added to this table > as if via |Object.defineProperties|. > > Bug fixes: > > > Object.defineProperty(x, "foo", {value: "bar", configurable: false, > writable: false, enumerable: true}; > > ... should have had a closing paren, and ... > > > // non-writable, but doesn't throw > > object.foo = "baz"; > > ... should have been ... > > // non-writable, but "set" trap still called > x.foo = "baz"; > > > 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
