[[Enumerate]] and enumerate and keys trap

Tom Van Cutsem tomvc.be at gmail.com
Mon Oct 8 10:57:57 PDT 2012

2012/10/8 Allen Wirfs-Brock <allen at wirfs-brock.com>

> 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?

I prefer the current symmetry with the existing built-ins:

Object.keys(proxy) // triggers handler.keys(target)
Object.getOwnPropertyNames(proxy) // triggers

It's just more learnable and consistent than routing these through a
getPropertyKeys trap.

Also, in a previous attempt to merge operations into a single trap (freeze,
seal, preventExtensions) we eventually circled back and left them separate,
on the grounds that most of the time you'd end up having to dispatch based
on the arguments to a dedicated operation anyway.

I'm all for internal spec refactorings to avoid duplication, but I feel
this particular refactoring is better left invisible to users.

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

More information about the es-discuss mailing list