possible excessive proxy invariants for Object.keys/etc??

Mark S. Miller erights at google.com
Sat Nov 24 23:35:52 PST 2012

+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

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 <dtribble at 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 <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
>> 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list