I am looking forward to proxies in JavaScript, and had a thought on the 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. Dean From: Allen Wirfs-Brock <[email protected]> > Date: Tue, Nov 20, 2012 at 2:18 PM > Subject: Fwd: possible excessive proxy invariants for Object.keys/etc?? > To: es-discuss discussion <[email protected]> > > > 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 <[email protected]> > Date: November 18, 2012 1:26:14 PM PST > To: Tom Van Cutsem <[email protected]>, "Mark S. Miller" < > [email protected]> > Cc: Jason Orendorff <[email protected]> > 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 > names). > > 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 > performed. > > 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 > properties. > > Allen >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
