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

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Nov 20 14:18:41 PST 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121120/5cd75f11/attachment.html>


More information about the es-discuss mailing list