[[Enumerate]] and enumerate and keys trap

Tom Van Cutsem tomvc.be at gmail.com
Mon Oct 8 11:34:35 PDT 2012

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

> Then we should also have the enumerate trap.

Absolutely. I wasn't arguing to get rid of it.

> I'm all for internal spec refactorings to avoid duplication, but I feel
> this particular refactoring is better left invisible to users.
> I definitely want the internal methods and traps to be completely
> parallel.  If we take the path suggested above I will add the equivalent of
> [[keys]] and  [[getOwnPropertyNames]] as essential internal methods and get
> rid of the parameters to [[Enumerate]].

I wouldn't mind if the [[Keys]], [[GetOwnPropertyNames]] and [[Enumerate]]
internal methods dispatched to an internal GetPropertyKeys helper function
with flags. In fact, why don't we let [[Keys]] and [[GetOwnPropertyNames]]
dispatch to a helper parameterized by just an "enumerableOnly" flag. The
[[Enumerate]] trap is the only one that does a proto-chain-walk, it
probably deserves its own internal method despite a little redundancy in
querying the own property names.

To summarize, we'd then have:

On built-in objects, call helper function
On proxies, call the "keys" trap

On built-in objects, call helper function
On proxies, call the "getOwnPropertyNames" trap

On built-in objects, specify an ad hoc algorithm that does the
On proxies, call the "enumerate" trap

> If that is the consensus, it should probably be captured as a spec. bug
> report.

Ok. Let's first see if everyone can agree to the above.

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

More information about the es-discuss mailing list