[[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:

[[Keys]]
On built-in objects, call helper function
GetPropertyKeys(enumerableOnly=true)
On proxies, call the "keys" trap

[[GetOwnPropertyNames]]
On built-in objects, call helper function
GetPropertyKeys(enumerableOnly=false)
On proxies, call the "getOwnPropertyNames" trap

[[Enumerate]]
On built-in objects, specify an ad hoc algorithm that does the
proto-chain-walk
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.

Cheers,
Tom
-------------- 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