[[OwnPropertyKeys]] key ordering
Mark S. Miller
erights at google.com
Sat Apr 19 11:21:10 PDT 2014
Awesome! Please let's do this!
I don't understand the comment about Object.keys, etc. If they continue to
be specified in terms of [[OwnPropertyKeys]], then they get cleaned up as
well, which seems good.
Is there a reason why we might want to continue to underspecify
If there is, how would you continue to underspecify Object.keys etc, while
still cleaning up [[OwnPropertyKeys]]?
Do we also have an opportunity to (finally!) pin down for/in ordering as
part of this?
On Sat, Apr 19, 2014 at 11:14 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:
> I'm in the middle of updating the spec. of [[OwnPropertyKeys]] to returns
> an Array rather than an Iterator. While doing this I realized that because
> [[OwnPropertyKeys]] is essentially a new MOP level operation we have the
> opportunity to precisely define the property key ordering it exposes for
> ordinary objects. This seems like a one-time opportunity that we shouldn't
> pass up.
> Note that this doesn't necessarily mean we need to change the
> unspecified/weakly specified ordering of exiting library functions such as
> Object.keys (even though they are specified in terms of
> [[OwnPropertyKeys]]). But it does mean that new library functions such as
> Reflect.ownKeys will be defined with a fully specified specified ordering.
> The ordering I propose is:
> 1) All array index property keys, in ascending array index numeric order.
> Followed by:
> 2) All other string property keys, in property creation order. Followed by:
> 3) All symbol property keys, in property creation order
> Does anybody see any reason why we shouldn't specify (this) property
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss