Unified class features spec text

[littledan]

We should write a combined piece of specification text covering this proposal, static class features, and private methods. The combined version would be more readable than the current three separate documents. Would anyone be interested in contributing this?

cc @feysalikbal

[feysalikbal]

I am interested to contribute on this. What guidelines do i need to follow?

[littledan]

That's great to hear! I am happy to have your help. See guidelines in https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md

[littledan]

@tjcrowder Would you be interested in taking on this task once you're through your existing queue? I think it'd complement the refactoring work you've been doing very well.

[tjcrowder]

@littledan - Great minds, I was planning to offer in fact, having seen https://github.com/tc39/proposal-private-methods/issues/50. It just makes sense, so many people will be implementing these all at the same time.

[littledan]

Great, thanks!

[tjcrowder]

@littledan - Okay, assuming that those PRs doing the syncing up between repos are okay (or that I can quickly fix them if not), I'll be done with this combined spec sometime in the morning. In it I reference the commits it's based on (so people will know when it's out of date), so I'll want for those PRs to get merged and refer to the commits on master.

[tjcrowder]

@littledan - Looks like you haven't had a chance to look at those PRs in detail yet (fair enough, I bet you're really busy prepping for next week, and/or travelling). I can't work on the combined spec on Friday, but I can on either Saturday or Sunday, so if they're in place then, I'll have it done before the meeting and can be sure to update it just before the meeting if there are further commits to the proposals.

I'm going to start by doing it manually for the first version. But all the time I'll be thinking about how to do it automatically instead, so subsequent commits automatically update the combined spec unless::

1. You think it's not worth doing that, although I worry about the almost immediate onset of rot. :-)
2. You think there's some chance they'll get re-combined into a single proposal at the meeting, making worrying about it unnecessary.

[littledan]

It would be awesome to automatically combine them! I don't know how to make that work, though. Manually combining them for the first pass SGTM.

1. It's definitely be useful, if you can figure out how to do it.
2. I don't plan to propose combining them.

[tjcrowder]

It might be possible (within reason) by adding markers or IDs in various places. We'll find out.

Separate question: The private methods and static methods proposals use one style for the values of [[Kind]], etc., and decorators uses a different style: the first two use ~method~, but decorators uses "method". Personally I prefer "method" (and that's the style used for [[ThisBindingStatus]] in function env recs, [[Order]] in shared memory event fields, etc.), but in any case they should match up. Which should I change?

[littledan]

Yeah, I noticed this recently too. Let's adopt "method".

[tjcrowder]

@littledan - A quick question on this: The class fields spec opens with a section called Lexical Grammar followed by New Syntactic Grammar Productions and then Updated Syntactic Grammar Productions. Is there a subtlety I'm missing there (entirely likely!), or should the two entries in Lexical Grammar be moved (the first into the new productions section, the second into the updated productions section)?

[littledan]

Lexical grammar was separated out for clarity, since the difference between lexical and syntactic grammar was pretty subtle for some readers. Let's leave it as is.