possible excessive proxy invariants for Object.keys/etc??
dtribble at gmail.com
Sat Nov 24 18:49:03 PST 2012
issues below. You could extend the the "direct proxy" approach for this.
When the Proxy receives getOwnPropertyNames, it
1) notifies the handler that property names are being requested
2) the handler adds/removes any properties (configurable or otherwise
subject to the normal constraints) on the target
3) upon return, the proxy invokes getOwnPropertyNames directly on the
target (e..g, invoking the *normal *system primitive)
This approach appears to have consistent behavior for configurability and
extensibility. For example, the trap operation above could add configurable
properties to an extensible target, and remove them later. It could add
non-configurable properties, but they are permanent once added, etc. Thus
there's no loss of generality. In addition to optionally setting up
properties on the target, the handler trap above would need to indicate to
the proxy (via exception or boolean result) that the getOwnPropertyNames
operation should proceed ahead or fail.
This extension of the "direct proxy" approach applies to all query
operations, eliminates the copying and validation overhead discussed below,
simplifies the implementation, retains full backwards compatibility, and
enables most if not all the expressiveness we might expect for proxies.
From: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Date: Tue, Nov 20, 2012 at 2:18 PM
> Subject: Fwd: possible excessive proxy invariants for Object.keys/etc??
> To: es-discuss discussion <es-discuss at mozilla.org>
> Tom Van Custem have been having some email discussion while I work on
> integrating Proxys into the ES6 spec. He and I agree that some
> broader input would be useful so I'm going to forward some of the
> message here to es-discuss and carry the discussion forward here.
> Here is the first message with other to follow:
> Begin forwarded message:
> From: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Date: November 18, 2012 1:26:14 PM PST
> To: Tom Van Cutsem <tomvc.be at gmail.com>, "Mark S. Miller" <
> erights at google.com>
> Cc: Jason Orendorff <jorendorff at mozilla.com>
> Subject: possible excessive proxy invariants for Object.keys/etc??
> I'm wondering if the wiki spec. for these functions aren't doing
> invariant checking that goes beyond what is required for the integrity
> purposes you have stated.
> In general, proxies traps check to ensure that the invariants of a
> sealed/frozen target object aren't violated. Generally, only minimal
> processing needs to be done if the target is extensible and has no
> non-configurable properties. In fact the Virtual Object proposal says
> "As long as the proxy does not expose non-configurable properties or
> becomes non-extensible, the target object is fully ignored (except to
> acquire internal properties such as [[Class]])." .
> The proxy spec.for Object.getOwnPropertyNames/kets/etc. seem to be
> doing quite a bit more than this. They
> 1) always copy the array returned from the trap? Why is this
> necessary? Sure the author of a trap should probably always return a
> fresh object but not doing so doesn't violate the integrity of the
> frozen/sealed invariants? In most cases they will provide a fresh
> object and copying adds unnecessary work that is proportional to
> the number of names to every such call.
> 2) ensuring that the list of property keys contains no duplicates.
> Why is this essential? Again, I don't see what it has to do with the
> integrity of the frozen/sealed invariants. It is extra and probably
> unnecessary work that is at least proportional to the number of
> 3) Every name in the list returned by the trap code is looked up on
> the target to determine whether or not it exists, even if the target
> is extensible. Each of those lookup is observable (the target might
> itself be a proxy) so, according to the algorithm they all must be
> 4) Every own property of the target, is observably looked up (possibly
> a second time) even if the object is extensible and has no
> non-configurable properties.
> It isn't clear to me if any of this work is really necessary to ensure
> integrity. After all, what can you do with any of these names other
> than use them as the property key argument to some other trap/internal
> method such as [[SetP]], [[DefineOwnProperty]], etc. Called on a
> proxy, those fundamental operations are going to enforce the integrity
> invariants of the actual properties involved so the get name checks
> doesn't really seem to be adding anything essential.
> Perhaps we can just get rid of all the above checking. It seems like
> a good idea to me.
> Alternatively, it suggests that a [[GetNonConfigurablePropertyNames]]
> internal method/trap would be a useful call to have as the integrity
> invariants only care about non-configurable properties. That would
> significantly limit the work in the case where there are none and
> limit the observable trap calls to only the non-configurable
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss