Status of this proposal

[adrianheine]

Are you also interested in listing parser implementations like acorn-class-fields?

[littledan]

@adrianheine Maybe we should link to https://github.com/tc39/proposal-class-fields/issues/57 for further tool support?

[adrianheine]

Oh yeah, I forgot about that :)

[Igmat]

Does it mean that there are no chances that current private implementation could be at least separated from this proposal and postponed till real consensus?

[ljharb]

Yes, since it already has real consensus.

[hax]

The words looks very muddling to me. It never explain why all alternatives were rejected, it even avoid word "rejection", huh.

I'm so disappointed that TC39 really(?!) got a consensus while the feedback of community say no and no again and again.

I won't say it's the darkest day of the history of TC39 after failure of ES4. But history will tell by itself.

[Igmat]

Yes, since it already has real consensus.

Probably there is consensus inside TC39 committee (even though I know at least one person from committee, who won't agree with it), but there is definitely NO consensus between TC39 and community, and I don't understand why do you ignore that.

Just check how many issues and discussion around private part of this proposal and ANY other stage 3 proposals.

You won't found such amount of disagreement for any other feature. And just closing issues without normal reasons isn't a good way to move.

[littledan]

I really think the perspective of the community outside of TC39 is very important, and want to take it into account as much as possible in our decision-making. I really want to continue GitHub repos as a communication medium to get more input into our specification process. And I apologize for not following and moderating the threads here in more detail; the volume just became very great. In particular, I'm sorry that I did not intervene more strongly when the discussion took a negative tone at times. I want you to know that your input is very important to me and many of us in TC39.

In addition to the discussions on GitHub, I've been talking with the authors of various libraries and frameworks, as well as people with more experience in more traditional object-oriented programming languages. For many of these folks, the lack of strong encapsulation boundaries that are easy to use is a big hole in JavaScript, and although it often took some time to get used to the syntax, it was seen as a practical option. I have the feeling that folks who felt positively about the proposal were less disposed to comment in GitHub issues, which are more of a way of expressing disagreement. The very long threads also probably created a barrier to entry to more people, both those who would be in favor of and opposed to this proposal.

Given the millions of JS developers in the world, there's no way an open process can include absolute consensus among the entire community, but that doesn't mean we should ignore it. Many of us in TC39 will keep trying our best to make decisions as community-informed as possible. But sometimes, we have to make hard choices, taking as much community input into account as possible, and making these choices is what TC39 is empowered to do.

[Igmat]

@littledan, I can agree with you. Especially in part related to entry barrier. It took me few weeks to inspect and analyze discussions around it.

I found out why do you insist on it and found some pluses in current solution, but it still has more cons than pros.

I even started to work on review for this proposal, which could be shared with larger audience in order to gather some kind of reasonable feedback, even though I have my day-to-day work and responsibilities, while activities like this has taken all my free time.

And in the end, you're telling about consensus (where did you find it?) and hard choices (leave proposal as is and do nothing to prevent issues raised dozens of times). It's dissapointing and I really can't understand why do you argue against separating privates from class-fields and revisit it once more. Or at least provide community with something that REALLY CAN solve our issues.

[Igmat]

@littledan and sorry about this, but your latest comment is just perfect example of wishful thinking.

[PinkaminaDianePie]

One thing which may solve all our issues someday is WebAssembly. When everyone will have a choice - there will be no need in arguing. JS won't die for sure, but developers won't be tightly coupled to a single language.

[littledan]

@Igmat We've spent many years looking into this topic. My feeling is that we're faced with some fundamental tradeoffs, and making a call at this point is more valuable for JS programmers in this case than spending more time to investigate further alternative options.

Re: wishful thinking: There's a lot we can improve on collecting and acting on community feedback. A number of us in TC39 are working on setting up various calls with segments of the community to get more feedback, to address the representation issue I wrote about above. If anyone wants to help with moderating GitHub threads, writing summaries of discussions for broader TC39 exposure, etc, that would make feedback here more actionable for us. Let me know if you'd be interested in getting involved in either of these efforts; you can email me at littledan@igalia.com .

@PinkaminaDianePie I'm excited about WebAssembly too! But you don't even have to wait for Wasm/GC integration to switch to other languages--compile-to-JS has worked out great for a lot of folks.

[zenparsing]

We should maybe not encourage people to abandon JS as a solution for disagreement with TC39 😄

[army8735]

I prefer private to #. As decorator syntax with @, maybe # will be used for another special syntax in future.

[hax]

@army8735 It will be a long story to explain why private not work, you could check my speech in QConBeijing 2017 . Though there are still many want to try private in some other form (you can check the closed issues like #56 in the repo). Personally I think the classes 1.1 proposal is the best alternative solution. But as we see, the committee refused all alternatives.

[hax]

I even started to work on review for this proposal, which could be shared with larger audience in order to gather some kind of reasonable feedback

I already did such thing last year in one of the biggest technical conference in China (QConBeijing). Note in that presentation I just explained why private not work, and why # is chosen, I never give any negative implication in the speech. But the feedback shows programmers don't like #priv solution. The most optimistic feedback I can get is "Too unfortunate! Ok, we can swallow it, just like we swallow all historical bad parts in the past." The drastic feedback is "We choose use TS private and will never use such terrible #priv". After that, I realize #priv is a bad solution because it will cause the JS community break. That's why I used all my free time to join the discussion of classes1.1 proposal which I think is the most hopeful alternative. I'm so disappointed all such efforts are failed and closed the door of any other alternatives. Actually, I don't think we could "collect feedback" in current situation, because most feedback will just be ignored.

[robpalme]

@hax Classes 1.1 was considered thoroughly when it was presented in the March 2018 meeting. At the end of the discussion, after hearing the debate, the presenter summed up the proposal as "I don't think the champions will take this forward. It's mostly just an idea. Don't take it too seriously."

[hax]

@robpalme That's what TC39 process failed. It seems they use "consensus in the room" rule. Normally it works, but for such controversial topic (change the direction of a stage 3 proposal) which have a very huge sunk cost, "consensus in the room" is a terrible process. Because you ignore the disagreement out of the room, and even in the room, it's very hard to say "you are wrong", "we are screwed", "we must stop it and try another path"... to the smart guys (maybe include yourself) who contribute several years on it! The supporters of this proposal are in the room unsurprisingly, and they know this is controversial but they want to push it to next stage anyway, so no is not welcome, alternative is not welcome, in fact they will not allow any "consensus in the room" on doing anything different. You will be see as a obstacle. It's just like on a one-way train which you do not have any way to stop it or change the direction of it. So after several such meetings, you just choose let it go and not enter the room and pray other could stop it.

Yes I'm not there, but this is not speculative. As I heard, one V8 contributor was asked to implement this proposal by the champion, and he refused. But even he don't like this proposal, he won't say it publicly because the champion is a nice person, a good friend. And eventually some other contributor implemented it.

And yesterday one TC39 member privately describe it to me: "some members don't really like it all that much but aren't willing to 'rock the boat' over it" and "some members who say no to the proposal before decide remain in the background now since they've been such a pain in the past and want to keep coming to TC39 for cooperation on other proposals".

Note, I don't want to simply blame the guys in the room. What I talked is human nature and the failure of the process.

---

To me, it's clear that TC39 should change the process, on this controversial topic.

For example, I suggest a anonymous ballot which require all TC39 members to vote. The questions can be simple:

1. Do you agree current status of the class field proposal have a big risk and push it in haste will be harmful to the whole JavaScript ecosystem?
2. Do you agree we should allow at least one competing proposal as the alternative, and the community should be allowed to have enough time and space to discuss, experiment (via babel/ts or even browser implementation behind the flag) and investigate the different possibilities for private requirements?
3. Do you agree we should freeze the stage of this proposal and ask js engine vendors keep their implementation under the flag before we have further real consensus like this ballot?

If 80%+ of the members give three no, then I would admit it's a real consensus, and I would stop and remove all my negative comments and would try my best to convince and educate other people in the China JS community that current proposal was the best solution we can get and we should embrace it for "harmony" of JS.

---

God bless JS.

[bakkot]

@hax, it is possible to stand up and say "no. the room wants this, but it is bad. do not do it", and thereby block a popular proposal. I've done so. The process simply does not work if people aren't willing to bring their objections forward. It also doesn't work if "some people don't really like it all that much" is sufficient to stop any proposal, because that is true of all but the very most trivial of proposals.

Anyway, we've revisited this at meetings again and again. People have brought up alternative designs. We've revisited proposals from most of a decade ago. I agree there's a chance that a silent majority thinks this is not roughly the best we could do (though I quibble with your questions; I don't think "there is risk" ought to be sufficient to stop a proposal, nor is there a meaningful sense in which competing proposals are "not allowed" as opposed to "not agreed with"; I would rather ask "do you think this is roughly the best we can do?" + "assuming if it is, do you think it's worth adding?" + "do you think a delay would be valuable to reassess those two questions?"), and if I have the time and energy I can see about performing a quick anonymous poll at the next meeting to check in. Though I have to say I'd be kinda disappointed to find that to be the case, because committee members who object to a thing need to bring up their objections for the process to work.

But I, for one, sincerely do not believe there's a significantly better proposal possible, and I don't think pushing this back another few years, after twenty years of circling this design space (including several years discussing exactly this proposal), would actually buy us anything at all. For further delays to be valuable there has to be some reason to think we'll come up with something significantly better, and I just do not think there's reason to believe that would the case.

[Igmat]

1. "do you think this is roughly the best we can do?" NO
2. "assuming if it is, do you think it's worth adding?" NO, if it is the best solution possible (with limitation that all we discussed dozens of times) it would be much better to NOT include such privates into language. I would rather live and work with language that forces tricky workarounds for encapsulation, than with language which adds additional meanings into encapsulation, because last will lead to terrible amount of missuses from other developers, that I can't control.
3. "do you think a delay would be valuable to reassess those two questions?" YES since it's better to have no private than existing one.

Missing privates - is existing environment, which could be improved. While proposed privates - is not yet existing environment, which couldn't be improved.

Once you land this proposal, one of generic metaprogramming approaches will be lost forever, unless brand-checking invariant will be revisited, but if there is a chance to revisit it later, than we could revisit it now.

P.S.

I'm not sure about this, but it seems that committee is stuck with some (unknown for community) assumptions and use-cases for privates and proxies. It seems that security scenarios (like using membranes and passing objects to untrusted environments) are taken as hard requirement and metaprogramming scenarios (like reactive properties) as nice-to-have. And IMO such assumption couldn't be taken as basics for language improvement without broader investigation and consensus.

I think that after so many years of discussions world (and JS ecosystem) could change in a way that actually dismisses some previous assumptions - and such amount of negative feedback could be a good reason to seriously revisit basics that used to evolve ES.

For example real world applications of proxies seems to dramatically differ from usage scenario they were built for...

[baiej214]

为什么非要搞一个官方的私有属性定义呢？这么多年大家都有自己的办法去解决这个问题。 如果必须要有，我个人建议使用大家经常使用的下划线，而不是#。 难道不觉着怪怪的吗？

[bakkot]

@baiej214, the problem with solutions like underscores is that they are only private by convention, rather than actually private. Library authors often find that people depend on those "kind of private" properties, even though they weren't supposed to, and that makes maintaining the libraries harder - they don't want to make changes which break their dependents, even if their dependents are doing things they weren't supposed to.

[wangking873]

private

[cupen]

No "Design by Committee".

[yw662]

Do not do this please.

Currently, we use "closure of constructor" for private members, which cannot be accessed by outside because of scope, which is actually a "perfect implementation" for private members of objects.

So, there is no need for another private member implementation.

Besides, CSS id selectors, URI fragments, shebangs and comments use character '#'. If JavaScript use this character, it might introduce incompatibility.

If you do want another private implementation, I suggest add a new property private to Object.prototype, and let any other constructors implement there own .prototype.private.

[trusktr]

@yw662 Can you elaborate on that with an example?

[gynet]

@robpalme That's what TC39 process failed. It seems they use "consensus in the room" rule. Normally it works, but for such controversial topic (change the direction of a stage 3 proposal) which have a very huge sunk cost, "consensus in the room" is a terrible process. Because you ignore the disagreement out of the room, and even in the room, it's very hard to say "you are wrong", "we are screwed", "we must stop it and try another path"... to the smart guys (maybe include yourself) who contribute several years on it! The supporters of this proposal are in the room unsurprisingly, and they know this is controversial but they want to push it to next stage anyway, so no is not welcome, alternative is not welcome, in fact they will not allow any "consensus in the room" on doing anything different. You will be see as a obstacle. It's just like on a one-way train which you do not have any way to stop it or change the direction of it. So after several such meetings, you just choose let it go and not enter the room and pray other could stop it.

Yes I'm not there, but this is not speculative. As I heard, one V8 contributor was asked to implement this proposal by the champion, and he refused. But even he don't like this proposal, he won't say it publicly because the champion is a nice person, a good friend. And eventually some other contributor implemented it.

And yesterday one TC39 member privately describe it to me: "some members don't really like it all that much but aren't willing to 'rock the boat' over it" and "some members who say no to the proposal before decide remain in the background now since they've been such a pain in the past and want to keep coming to TC39 for cooperation on other proposals".

Note, I don't want to simply blame the guys in the room. What I talked is human nature and the failure of the process.

To me, it's clear that TC39 should change the process, on this controversial topic.

For example, I suggest a anonymous ballot which require all TC39 members to vote. The questions can be simple:

1. Do you agree current status of the class field proposal have a big risk and push it in haste will be harmful to the whole JavaScript ecosystem?
2. Do you agree we should allow at least one competing proposal as the alternative, and the community should be allowed to have enough time and space to discuss, experiment (via babel/ts or even browser implementation behind the flag) and investigate the different possibilities for private requirements?
3. Do you agree we should freeze the stage of this proposal and ask js engine vendors keep their implementation under the flag before we have further real consensus like this ballot?

If 80%+ of the members give three no, then I would admit it's a real consensus, and I would stop and remove all my negative comments and would try my best to convince and educate other people in the China JS community that current proposal was the best solution we can get and we should embrace it for "harmony" of JS.

God bless JS.

@hax Although I am not happy with the proposal, but i am more worried about the "consensus in the room" rule and the current TC process. Running by the rule, it might not be surprised why Chrome and Firefox are silent on implementing the ES6 standard of "Tail Recursion Optimization".

[bakkot]

@gynet

Running by the rule, it might not be surprised why Chrome and Firefox are silent on implementing the ES6 standard of "Tail Recursion Optimization".

Proper tail calls were added to the spec prior to the adoption of the current process. In fact, the current process was adopted specifically to prevent things like that from happening in the future.

[rdking]

I want to ask this about the process. Mind you, for as much as I enjoy a good argument, I have no intentions of doing so with this.

How can it be said that there is a "consensus" in the presence of political pressure and dissenting opinion? And doesn't the current process place too much value on "no"? Even if 99% of "the room" actually likes a proposal, all it takes is 1 "no" and that proposal is frozen. Given that competing proposals can come up, how unlikely is it that "no" can be prevent from a party vested in a competing proposal?

What I'm thinking is that when "aye" and "nay" don't have the same weight, no "consensus" can ever be reached. What's needed is a method of drawing a consensus that is balanced and not nearly as prone to political pressure beyond direct negotiation.

[ljharb]

@rdking if your conclusion was correct, we’d never reach consensus, yet we often do.

[rdking]

@ljharb Ok, I'll grant you poor wording on my part. Let me try to be a little more clear.

When I hear "consensus", I think that "there may be a few that absolutely don't want this, but a significant majority have actively given consent". However, when a tc39 member says "consensus", they mean "There were probably dissenters in the room, but none willing to openly say no". When I said no "consensus" can eve be reached., I should have added "for highly controversial proposals".

Given what I've come to understand about the process and opinions of various tc39 members, I'd say you have reached a pressured tacit agreement more-so than a consensus. In the absence of an active vote, where a single "nay" can kill a valued proposal, tc39 will tend toward a Mexican standoff. But because no one is willing to "shoot" (say no), the proposal passes with a "consensus" (pressured tacit agreement).

Granted I've hyperbolized things a bit. So, can you answer the 3 questions above?

[ljharb]

It can be said because “consensus” and “agreement” are different words; the former does not imply the latter. The current process places the correct amount of value on “no” because “a bad change we can never remove” is infinitely more costly than “nothing new ever happens”.

I’m not sure what your third question is asking; nobody has any power to prevent a “no” from torpedoing any proposal (competing or otherwise), at least prior to stage 3 where web reality might kick in.

[rdking]

The current process places the correct amount of value on “no” because “a bad change we can never remove” is infinitely more costly than “nothing new ever happens”.

While I understand the reasoning and agree to a point, isn't that perspective a little myopic? A simple "no" to a newly introduced proposal with no competition makes sense. A "no" to the introduction of competition or changes to the proposal seems to require both justification from the dissenter, and acceptance of that justification from the remainder of the board.... at least IMO. However, here a simple "no" gains far too much power with how tc39 currently does things.

What I'm trying to say is that, given the quote above, where "no" is used to prevent a "bad change", there's also the flip side where that same "no" can be used to push through a "bad change". I would expect that even though you may not think such a thing has happened or is happening, you can certainly understand how it might.

[ljharb]

That’s only if you assume bad faith - if you assume good faith, then a “no” means the competing proposal isn’t sufficient (for whatever reason).

We’re all here with good intentions, trying our best - nobody’s trying to game the system to force things through.

Since we’re talking about process, and not this proposal, let’s plead not continue with what’s off topic here.

[rdking]

I try not to assume either. I tend towards assuming humans will be human. At any point in time, any of us can go from acting in "good faith" to acting in "enlightened self-interest" or vice versa. The problem with "enlightened self-interest" is that the "others" for whom the "good" is intended may only be a small subset of those who will be affected by the "good", and for those affected outside that subset, the "good" is definitively not.

Incurring a single no from such an "enlightened self interest" is still, as you say, acting with "good intentions". However, the ability of a single "no" to prevent a "good" for the majority because of dissent from a minority, even though all are acting in "good faith", still grants "no" too much power in certain scenarios.

I'll end my side of the discussion here, but I'm still curious about your response.

[littledan]

I am not sure if this is the best place to clarify TC39's process. We're working on documentation about how TC39 works (unfortunately, not ready for publication yet); let's try to document it there.

[rdking]

Fair enough. While TC39 is working on that documentation, it might be a good idea to spin up a repo to contain such discussions. These discussions might shed some light not only on the process itself, but also how to both document and improve it, as well as explain why it is the way it is.

[littledan]

We are working on improvements to our documentation of our process. However, I am not sure if the repo with that documentation will be a great place to discuss improvements either; that's more about documenting what it is currently.

Ultimately, it's up to the committee to decide on its process. You have made your suggestions clear already, and I have already passed them onto my colleagues. I am not sure if discussing them at more length will be the best way to bring about changes.

[rdking]

You have made your suggestions clear already, and I have already passed them onto my colleagues.

Thank you for listening.

[gynet]

@robpalme That might be a problem. How could the "consensus process" tell if the "proposal-class-field" is more needed for the community rather than "Tail Recursion Optimization"?