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
