[[Enumerate]] and enumerate and keys trap

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Oct 8 09:42:40 PDT 2012

On Oct 8, 2012, at 9:29 AM, Tom Van Cutsem wrote:

> 2012/10/8 David Bruant <bruant.d at gmail.com>
>  If the internal [[Enumerate]] only deals with own properties, it seems that the enumerate trap can be removed and for..in loop can use the keys and getPrototypeOf traps instead (as it does with regular objects which was my point 2).
> It all sounds plausible. For proxies and for-in loops there's an important inversion-of-control though: currently the proxy takes control of a for-in loop (it decides whether to continue the loop with its prototype), with your proposal the proxy would lose that control. For all other traps that may be called during a prototype-chain-walk (get, set, has) the proxy always gets to "virtualize its prototype chain".

I agree, removing the [[Enumerate]] trap would limit a proxy's ability to control the interpretation of its prototype chain.  I don't think we should do thjat.

> Even if not adopting the changes I just suggested, it seems that we need some harmonization between the proxy traps and the internal [[Enumerate]] signatures.
> Indeed. If we stick with the current [[Enumerate]](includePrototype, onlyEnumerable) signature we'll need an ugly preamble for proxies:
> - when includePrototype is false and onlyEnumerable is true, call the keys trap
> - when includePrototype is false and onlyEnumerable is false, call the getOwnPropertyNames trap
> - when includePrototype is true and onlyEnumerable is true, call the enumerate trap
> - any other combination should not occur

With the [[Enumerate]] trap parameters I was trying to minimize the number of essential internal methods.  I don't see why we couldn't carry that forward to traps.  A single [[GetPropertyKeys]] internal method/trap with includePrototype and onlyEnumerable arguments would seem to cover the all of the use cases of the enumerate, keys and getOwnPropertyNames traps.  Why not just have that single trap?


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

More information about the es-discuss mailing list