In the January 2018 TC39 meeting, I presented the version of this proposal which is based on static public fields and lexically scoped hoistable declarations in class bodies (slides, notes). This issue summarizes my understanding of the feedback, both in and around the meeting, and a possible direction for next steps.
Static public fields
Overall, I've heard really strong support of static public fields. It seems to be a very widely used pattern in JS programmers' code, which makes sense for us to reify into a language feature.
@waldemarhorwat was skeptical of how public static fields are inherited as data properties in the prototype chain.
@allenwb has explained that static in JavaScript classes means "of the constructor", with all the normal semantics, including inheritance. This interpretation seems to justify the inheritance results @waldemarhorwat was concerned about.
Lexical declarations in class bodies
The strongest support from this proposal came from several people (@erights, @zenparsing, @allenwb) who saw it as an alternative to supercede private methods. I've responded to this proposal on GitHub.
I didn't hear any direct support for the claim I was trying to make, that private instance methods and lexically scoped function declarations in class bodies are natural complements.
It's still not clear if we'll be able to come to consensus on what the surface syntax should be, namely whether there should be a token (e.g., local) preceding a function declaration in a class body. @waldemarhorwat opined that an additional token is an additional thing to learn which breaks orthogonality and doesn't add anything, and that it shouldn't be part of the surface syntax.
However, many others who have reviewed this proposal have found lexically scoped function declarations to be only acceptable because an additional token differentiates it from method declarations. @wycats explained that class bodies currently don't have anything in common with ordinary code at all, and that it would confuse the metaphor to include statement-like things in that context (with function being perhaps "less bad" than let, const or class declarations).
A couple people commented offline that maybe private methods could be enough, and the motivating example might not have been strong enough. This post explores that proposition--in all the examples I can think of, all you have to do to use private methods for a factory pattern could be split in two--the stuff that runs before allocation (which could be a lexically scoped function defined outside of the class), and the stuff that runs after (a private instance method).
Bigger picture feedback
Generally, I heard a lot more feedback about things that we shouldn't do rather than that we must do things. Static public fields, and some kind of function or method which can access private instance fields, are widely shared goals. At the same time, a number of people cautioned against introducing excessive complexity into the language.
Different groups of committee members have expressed wanting to go in a direction either based on static private or lexical scoping, each group with intuition that they are the most intuitive and general programming models for JavaScript. We've also advanced in thinking through proposals for private name declarations outside of classes (e.g., @rauschma) and static blocks in classes (e.g., @rbuckton), additional ways to get at some of the same problem space.
Luckily, at this point, we have looked into several alternatives in detail, discussed various intuitions committee members have about their syntax and edge cases, and are further along in developing them than we were a few months ago. Documentation of their details can be found in various places, scattered around this repository.
Next steps
I'm thinking of proposing static public fields for re-promotion to Stage 3 and helping others pursue other class features in follow-on, separate staged proposals.
Why static public fields are ready
One thing that we've learned through the process of examining several alternative proposals in detail is that none of them have an unresolvable conflict with the semantics of static public fields. We've also not yet come across feasible alternative semantics for static public fields.
TC39 demoted static public fields to Stage 2 together with static private class features in order to make sure that we thoroughly consider alternatives and don't advance things in a way that is not well thought through or prematurely cuts off reasonable follow-on proposals. I think we've done our requested homework.
Developing follow-on proposals
This repository currently contains a lot of information about various follow-on proposals already, though it's voiced in a frame of "this is selected over the others for the following reason". I don't see entirely fatal flaws in any of them, but rather tradeoffs that we could decide to make one way or another (but whose decision will not make us regret the static public fields design).
The next step here would be to write explainers for these follow-on proposals and bring them to committee. Could we identify champions for each of these proposals to write this document? I'm happy to help out champions however I can.
Static private (champion?)
Lexically scoped declarations in class bodies (champion?)
Private names declared outside of class bodies (champion?)
In the January 2018 TC39 meeting, I presented the version of this proposal which is based on static public fields and lexically scoped hoistable declarations in class bodies (slides, notes). This issue summarizes my understanding of the feedback, both in and around the meeting, and a possible direction for next steps.
Static public fields
staticin JavaScript classes means "of the constructor", with all the normal semantics, including inheritance. This interpretation seems to justify the inheritance results @waldemarhorwat was concerned about.Lexical declarations in class bodies
local) preceding a function declaration in a class body. @waldemarhorwat opined that an additional token is an additional thing to learn which breaks orthogonality and doesn't add anything, and that it shouldn't be part of the surface syntax.functionbeing perhaps "less bad" thanlet,constorclassdeclarations).Bigger picture feedback
Generally, I heard a lot more feedback about things that we shouldn't do rather than that we must do things. Static public fields, and some kind of function or method which can access private instance fields, are widely shared goals. At the same time, a number of people cautioned against introducing excessive complexity into the language.
Different groups of committee members have expressed wanting to go in a direction either based on static private or lexical scoping, each group with intuition that they are the most intuitive and general programming models for JavaScript. We've also advanced in thinking through proposals for private name declarations outside of classes (e.g., @rauschma) and static blocks in classes (e.g., @rbuckton), additional ways to get at some of the same problem space.
Luckily, at this point, we have looked into several alternatives in detail, discussed various intuitions committee members have about their syntax and edge cases, and are further along in developing them than we were a few months ago. Documentation of their details can be found in various places, scattered around this repository.
Next steps
I'm thinking of proposing static public fields for re-promotion to Stage 3 and helping others pursue other class features in follow-on, separate staged proposals.
Why static public fields are ready
One thing that we've learned through the process of examining several alternative proposals in detail is that none of them have an unresolvable conflict with the semantics of static public fields. We've also not yet come across feasible alternative semantics for static public fields.
TC39 demoted static public fields to Stage 2 together with static private class features in order to make sure that we thoroughly consider alternatives and don't advance things in a way that is not well thought through or prematurely cuts off reasonable follow-on proposals. I think we've done our requested homework.
Developing follow-on proposals
This repository currently contains a lot of information about various follow-on proposals already, though it's voiced in a frame of "this is selected over the others for the following reason". I don't see entirely fatal flaws in any of them, but rather tradeoffs that we could decide to make one way or another (but whose decision will not make us regret the static public fields design).
The next step here would be to write explainers for these follow-on proposals and bring them to committee. Could we identify champions for each of these proposals to write this document? I'm happy to help out champions however I can.