{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecma262/issues/1819","repository_url":"https://api.github.com/repos/tc39/ecma262","labels_url":"https://api.github.com/repos/tc39/ecma262/issues/1819/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma262/issues/1819/comments","events_url":"https://api.github.com/repos/tc39/ecma262/issues/1819/events","html_url":"https://github.com/tc39/ecma262/issues/1819","id":541356177,"node_id":"MDU6SXNzdWU1NDEzNTYxNzc=","number":1819,"title":"Does EnumerateObjectProperties have specified order enumeration?","user":{"login":"dSalieri","id":34900769,"node_id":"MDQ6VXNlcjM0OTAwNzY5","avatar_url":"https://avatars2.githubusercontent.com/u/34900769?v=4","gravatar_id":"","url":"https://api.github.com/users/dSalieri","html_url":"https://github.com/dSalieri","followers_url":"https://api.github.com/users/dSalieri/followers","following_url":"https://api.github.com/users/dSalieri/following{/other_user}","gists_url":"https://api.github.com/users/dSalieri/gists{/gist_id}","starred_url":"https://api.github.com/users/dSalieri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dSalieri/subscriptions","organizations_url":"https://api.github.com/users/dSalieri/orgs","repos_url":"https://api.github.com/users/dSalieri/repos","events_url":"https://api.github.com/users/dSalieri/events{/privacy}","received_events_url":"https://api.github.com/users/dSalieri/received_events","type":"User","site_admin":false},"labels":[{"id":91296571,"node_id":"MDU6TGFiZWw5MTI5NjU3MQ==","url":"https://api.github.com/repos/tc39/ecma262/labels/question","name":"question","color":"fbca04","default":true,"description":null}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":15,"created_at":"2019-12-21T18:26:18Z","updated_at":"2019-12-31T02:56:43Z","closed_at":null,"author_association":"NONE","body":"My question sounds as: in chapter [13.7.5.15 EnumerateObjectProperties](https://www.ecma-international.org/ecma-262/10.0/#sec-enumerate-object-properties) we have the following steps of the algorithm:\r\n>1. Assert: Type(O) is Object.\r\n>2. Return an Iterator object (25.1.1.2) whose next method iterates over all the String-valued keys of enumerable properties of O. The iterator object is never directly accessible to ECMAScript code. **The mechanics and order of enumerating the properties is not specified but must conform to the rules specified below.**\r\n\r\nIf we read further, we will see the following entry:\r\n>EnumerateObjectProperties must obtain the own property keys of the target object by calling its [[OwnPropertyKeys]] internal method. \r\n\r\nQuestion: why is it written above that `order of enumerating the properties is not specified`, if the operation [[OwnPropertyKeys]] is concrete specified, which describes in what sequence the property keys should go.\r\n\r\nI saw a lot of questions on SO about this issue. But the answers were different since some said that there is order, while others did not, please clarify the situation"},"comment":{"url":"https://api.github.com/repos/tc39/ecma262/issues/comments/569853052","html_url":"https://github.com/tc39/ecma262/issues/1819#issuecomment-569853052","issue_url":"https://api.github.com/repos/tc39/ecma262/issues/1819","id":569853052,"node_id":"MDEyOklzc3VlQ29tbWVudDU2OTg1MzA1Mg==","user":{"login":"jmdyck","id":4344001,"node_id":"MDQ6VXNlcjQzNDQwMDE=","avatar_url":"https://avatars0.githubusercontent.com/u/4344001?v=4","gravatar_id":"","url":"https://api.github.com/users/jmdyck","html_url":"https://github.com/jmdyck","followers_url":"https://api.github.com/users/jmdyck/followers","following_url":"https://api.github.com/users/jmdyck/following{/other_user}","gists_url":"https://api.github.com/users/jmdyck/gists{/gist_id}","starred_url":"https://api.github.com/users/jmdyck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmdyck/subscriptions","organizations_url":"https://api.github.com/users/jmdyck/orgs","repos_url":"https://api.github.com/users/jmdyck/repos","events_url":"https://api.github.com/users/jmdyck/events{/privacy}","received_events_url":"https://api.github.com/users/jmdyck/received_events","type":"User","site_admin":false},"created_at":"2019-12-31T02:56:43Z","updated_at":"2019-12-31T02:56:43Z","author_association":"COLLABORATOR","body":"> [...] the internal method `[[OwnPropertyKeys]]` from the ECMAScript model in the specification implementation is required to return a list of property keys in the order described by the specification, namely:\r\n> \r\n> > [steps from OrdinaryOwnPropertyKeys]\r\n\r\nYes, but that particular order is required only for ordinary objects.\r\n\r\n> Do I understand correctly that the order of adding keys to the list is still important?\r\n\r\nYes, because it's completely observable.\r\n\r\n> Since in the ECMAScript model we observe specifically this order for property keys that are proprietary to the object.\r\n> This can be seen by various methods: `Object.keys, Object.values, Object.entries, Reflect.ownKeys`\r\n\r\nNote that Object.keys, Object.values, and Object.entries invoke EnumerableOwnPropertyNames, which exposes only String-valued property keys, so they don't allow you to observe the effect of step 4 of OrdinaryOwnPropertyKeys. But Reflect.ownKeys does, because it exposes *all* own property keys.\r\n\r\n---\r\n\r\n> But remember your following statement:\r\n> \r\n> > 6.1.7.3 doesn't require that [[OwnPropertyKeys]] return property keys in a particular order. Most kinds of object do specify a particular order, but Proxy objects don't, and non-standard exotics aren't required to.\r\n> \r\n> But this conflicts with the statement:\r\n> \r\n> > The spec doesn't have a special way to convey that the order of execution of an algorithm's steps is important -- that's the default. I.e., you have to assume that order is important unless you can prove otherwise.\r\n\r\nThe two statements don't conflict. 6.1.7.3 doesn't impose a constraint on the order of keys returned by any `[[OwnPropertyKeys]]` method, but specific `[[OwnPropertyKeys]]` methods are free to specify a particular order.\r\n\r\n> How would I suggest that in the `[[OwnPropertyKeys]]` internal method, the order in which the properties are added matters.\r\n\r\nNot sure what you mean. Suggest to whom? One way to show someone that that order matters is to point to the definition of Reflect.ownKeys.\r\n\r\n> Otherwise, the specification would write that the properties can be added to the list in any convenient way.\r\n\r\nYes, something like that.\r\n\r\n---\r\n\r\n> And by the way:\r\n> \r\n> > > If the implementation does not follow [[OwnPropertyKeys]], then why is it defined by the specification?\r\n> > \r\n> > To indirectly specify constraints on some of the behavior that the implementation must exhibit.\r\n> \r\n> That is, still `[[OwnPropertyKeys]]` imposes constraints, and what are these constraints in this case?\r\n\r\nThat depends on what \"this case\" is. If you're talking about *any* object, then the constraints are only those imposed by 6.1.7.3. But if you're talking about a specific kind of standard-defined object, then the constraints are those imposed by the relevant definition of `[[OwnPropertyKeys]]`.\r\n\r\n> A rather confusing situation regarding `[[OwnPropertyKeys]]` has developed\r\n\r\nIt's not clear to me what you're confused about.\r\n"}}
{"actor":{"display_login":"jmdyck"}}