Ordering requirements
littledan opened this issue · 9 comments
In your new functions, you have the following sentence:
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 5.
Looks like you included this because the ES2015 specification includes a similar statement about Object.keys. However, it seems redundant: the definition calls out to [[OwnPropertyNames]], which already has well-defined ordering on objects. The normative statement seems to only has an effect in terms of limiting how for-in works to match [[OwnPropertyNames]], which I don't think was the intent of the specification authors.
Seems like this should be fixed both here and the main specification. @anba @bterlson what do you think?
If it's fixed in the main spec, I'll be happy to remove it here - but I want to be absolutely explicit that all three functions should have identical ordering.
It is clear that keys, values, and entries don't have anything to do with enumeration order - they delegate to [[OwnPropertyKeys]], get back a list, and process it in list order. This may need to exist, though, because host objects could have their own crazy implementations of [[OwnPropertyKeys]] and [[Enumerate]] and the sentence basically says, if you have a weird object, [[OwnPropertyKeys]] better return properties in the same order as [[Enumerate]] would visit them?
That's kind of what I was thinking - better to overspecify here than underspecify, since property key ordering is a wild west historically.
[[OwnPropertyKeys]] is already specified well. If you want to put in more specification, put it in the definition of for-in loops. If you want to declare a correspondence between them, it seems like it should be in a note. Putting multiple overlapping pieces of specification, which might actually disagree with each other, just leads to confusion about what the real definition is. Better to have just one real definition and other non-normative notes to clarify if they're useful.
Where is [[OwnPropertyKeys]] rigorously specified for host objects?
Note that this spec calls into what will be the former [[EnumerableOwnNames]] , which then calls into [[OwnPropertyKeys]] - and [[EnumerableOwnNames]] also specifies in a "NOTE" (which i now understand to be non-normative) "The order of elements in the returned list is the same as the enumeration order that is used by a for-in statement.".
Thus, since it's non-normative, but the statements on keys/values/entries are normative (since they lack "note"), don't these still have value?
@littledan, the linked section is for ordinary objects. Hosts can provide exotic objects that don't implement that slot as specified for ordinary objects.
Seems like this should be closed - please let me know if it should be reopened.