Spec text editor signoff?

[ljharb]

@bterlson, you're up :-) the designated reviewers have signed off in #8.

Can you review the spec text? I'd love to shoot for stage 3 at the November meeting.

[bterlson]

• Remove explicit length unless needed.
• Clause 4 step 6 seems superfluous given the prose at the end of clauses 1-3.

Otherwise seems fine. There is a bit of duplication here with GetOwnPropertyKeys but given that that API returns an Array not a List I am not sure if it's worth using it :-P.

[ljharb]

Thanks, I've removed the length.

Regarding Clause 4 step 6 - this is present in the current spec in both Object.keys and EnumerableOwnNames - I think that if it should be removed from EnumerableOwnNames, it should be done directly to the spec and not as part of this proposal.

Regarding GetOwnPropertyKeys - unlike EnumerableOwnNames, which only returns enumerable string keys, GetOwnPropertyKeys also returns nonenumerable keys, and can return either String or Symbol keys. I could refactor EnumerableOwnProperties to call GetOwnPropertyKeys with a Type of String, but then I'd need to use an enumerability check in step 5.a - so EnumerableOwnProperties wouldn't get any simpler. Alternatively, if I implemented GetOwnPropertyKeys in terms of EnumerableOwnProperties - then EnumerableOwnProperties wouldn't be "Enumerable" anymore. In other words, I don't think this is actual duplication, nor do I think it's easily resolved, without a mega-method that allowed for specifying "enumerable or non-enumerable or both", as well as "string or symbol or both" - it'd be pretty hairy.

Given these, do you think this can be counted as officially signed off?

[ljharb]

This has been officially signed off, and the proposal is now at stage 3!