[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Thu May 5 11:38:47 PDT 2011

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

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


2011/5/5 Sean Eagan <seaneagan1 at gmail.com>

> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110505/0ccd764f/attachment.html>

More information about the es-discuss mailing list