+1. I think this is a really effective extension of the direct proxy approach, and I don't know why we didn't see it earlier. It's weird that this preserves all the flexibility of fully virtual configurable properties even though it insists that even these be made into real properties on the target. The trick is that placing a configurable property on the target doesn't commit the handler to anything, since the handler can remove or change this property freely as of the next trap.
Apologies again for not yet having the time to do more than skim the thread at this point. But IIRC someone already suggested a similar change to some of the imperative traps -- perhaps freeze, seal, and preventExtensions. The handler would not perform these operations on the target, only to have the proxy check it. Rather, if the trap indicates that the operation should succeed, the proxy then simply performs the operation -- or else throws. I wonder if this philosophy could be extended to some of the other imperative operations as well? What expressiveness does this even-more-direct proxy approach lose? AFAICT, not much. At the same time, it should result in a *much* simpler implementation and much greater confidence that invariants of the non-proxy sublanguage are preserved by the introduction of proxies. In fact, I think it's much stronger on invariant preservation that the current direct proxies, while being much simpler. On Sat, Nov 24, 2012 at 6:49 PM, Dean Tribble <dtrib...@gmail.com> wrote: > 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 <al...@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@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 <al...@wirfs-brock.com> >> Date: November 18, 2012 1:26:14 PM PST >> To: Tom Van Cutsem <tomvc...@gmail.com>, "Mark S. Miller" >> <erig...@google.com> >> Cc: Jason Orendorff <jorendo...@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 >> 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
