Impossible ordering requirement in EnumerableOwnNames

[rossberg]

7.3.21 (EnumerableOwnNames(O)), step 5 requires to "order the elements of names so they are in the same relative order as would be produced by the Iterator that would be returned if the [[Enumerate]] internal method was invoked on O." That list of names was originally obtained from O.[[OwnPropertyKeys]].

Since O may be a proxy, this requirement is impossible to meet.

[littledan]

Some other language which doesn't have these proxy implications can be found at the end of Object.keys (which calls EnumerableOwnNames):

If an implementation defines a specific order of enumeration for the for-in statement, the same order must be used for the elements of the array returned in step 3.

Not sure why this is in normative test and not a note, especially seeing this logic in EnumerableOwnNames; I brought this up previously at tc39/proposal-object-values-entries#6 .

We could do a similar thing here, maybe. For example,

5- If this is an ordinary object and an implementation defines a specific order of enumeration for [[Enumerate]] for this kind of Object, reorder the elements of names so they are in the same relative order as the output of [[Enumerate]].

Another funny thing about it is that a for-in loop/[[Enumerate]] will only have String keys, whereas EnumerableOwnNames may have Symbol keys, but maybe we can just assume that the Symbols are left at the end. So the spec text could read something like,

5- If this is an ordinary object and an implementation defines a specific order of enumeration for [[Enumerate]] for this kind of Object, reorder the elements of names so they are in the same relative order as the output of [[Enumerate]], leaving any Symbol elements at the end.

[littledan]

Some other language which doesn't have these proxy implications can be found at the end of Object.keys (which calls EnumerableOwnNames):

If an implementation defines a specific order of enumeration for the for-in statement, the same order must be used for the elements of the array returned in step 3.

Not sure why this is in normative test and not a note, especially seeing this logic in EnumerableOwnNames; I brought this up previously at tc39/proposal-object-values-entries#6 .

We could do a similar thing here, maybe. For example,

5- If this is an ordinary object and an implementation defines a specific order of enumeration for [[Enumerate]] for this kind of Object, reorder the elements of names so they are in the same relative order as the output of [[Enumerate]].

Another funny thing about it is that a for-in loop/[[Enumerate]] will only have String keys, whereas EnumerableOwnNames may have Symbol keys, but maybe we can just assume that the Symbols are left at the end. So the spec text could read something like,

5- If this is an ordinary object and an implementation defines a specific order of enumeration for [[Enumerate]] for this kind of Object, reorder the elements of names so they are in the same relative order as the output of [[Enumerate]], leaving any Symbol elements at the end.

[rossberg]

Since [[Enumerate]] will normally group the properties per object on the prototype chain, I don't think it's right to put all symbols at the end. They'd at least have to be interleaved such that they are at the end of each respective object's group.

[rossberg]

Since [[Enumerate]] will normally group the properties per object on the prototype chain, I don't think it's right to put all symbols at the end. They'd at least have to be interleaved such that they are at the end of each respective object's group.

[anba]

Symbol-valued property keys are already filtered in the EnumerableOwnNames loop.

[anba]

Symbol-valued property keys are already filtered in the EnumerableOwnNames loop.

[rossberg]

Good point! :)

[rossberg]

Good point! :)

[littledan]

Oops, another spec misreading on my part! @anba what do you think of the rest of the rewording, clarifying that the correspondence with for-in is only guaranteed for ordinary Objects? I don't think this is a big normative change or needs discussion at TC39.

[littledan]

Oops, another spec misreading on my part! @anba what do you think of the rest of the rewording, clarifying that the correspondence with for-in is only guaranteed for ordinary Objects? I don't think this is a big normative change or needs discussion at TC39.

[anba]

The reordering should also happen for Array or Arguments objects, so I'd propose to use:

5. If O.[[Enumerate]] is the ordinary object [[Enumerate]] internal method (9.1.11), then
   1. Order the elements of names so they are in the same relative order as would be produced by the Iterator that would be returned if the [[Enumerate]] internal method was invoked on O.

[anba]

The reordering should also happen for Array or Arguments objects, so I'd propose to use:

5. If O.[[Enumerate]] is the ordinary object [[Enumerate]] internal method (9.1.11), then
   1. Order the elements of names so they are in the same relative order as would be produced by the Iterator that would be returned if the [[Enumerate]] internal method was invoked on O.

[littledan]

@anba How could you evaluate what order would be produced by the iterator if O is a Proxy?

[littledan]

@anba How could you evaluate what order would be produced by the iterator if O is a Proxy?

[anba]

I don't understand that question. If O is a Proxy, then O.[[Enumerate]] is not the ordinary object [[Enumerate]] internal method.

[anba]

I don't understand that question. If O is a Proxy, then O.[[Enumerate]] is not the ordinary object [[Enumerate]] internal method.

[littledan]

Oh, I see. Yes, that spec text looks good to me.

[littledan]

Oh, I see. Yes, that spec text looks good to me.

[bterlson]

Sorry for the delay here. Going to implement @anba's proposal now.

[bterlson]

Sorry for the delay here. Going to implement @anba's proposal now.