Do we still have a chance to stop private fields (with #)?

[SCLeoX]

It is clear to me that this "consensus" in the committee is against the majority of the community other than tc39.

I just want to know, what people like me, who really do not want this private fields thing (with #) to be added into JavaScript, can do to prevent it from happening.

[littledan]

Honest question: How do you think we in TC39 should assess how the majority of the community will feel about a proposal once they try it out a bit? I want to figure out how we can improve the process for future proposals.

(I suggested that we require a transpiler implementation earlier in the process, but this suggestion was rejected by the committee; anyway, just an implementation isn't enough without a mechanism for collecting feedback.)

[mbrowne]

Just FYI to anyone who isn't aware, private fields using # are now available in Babel 7. I agree it would have been good if this had happened much earlier.

...and I just noticed that the readme of this repo has been updated as well, with the status of several implementations in progress, including a native one in Chrome (behind a flag).

[littledan]

Yes, delaying the Babel implementation was definitely an error on my part in this proposal.

[SCLeoX]

@littledan I think there should be a vote or something of similar nature when a proposal is controversial.

I had a discussion in a JavaScript group with a couple experienced JavaScript developer. We come to a consensus very quickly that the idea of having private fields are awesome, but # is just too ugly and weird.

Usually, when there is a new feature being add to JavaScript, we really get hyped but it is just not the case this time.

[jhpratt]

@SCLeoX And what is the alternative to #? The private keyword was rejected because it didn't meet all of the TC39's requirements.

[mbrowne]

@SCLeoX regarding developers who would vote solely based on their initial reactions of finding it "ugly and weird", without taking the time to deeply understand the technical considerations, I am glad that just the average developer cannot vote (and just to be clear, I am not a member of the committee). If the committee just had 2 or 3 members and/or they were totally disconnected from the community, that would be a real problem, but fortunately I think the community is overall pretty well-represented on the committee. At least 95% of the complaints about the syntax are coming from people who haven't really considered the technical issues involved, including those mentioned in the FAQ.

[SCLeoX]

@jhpratt That is my problem though. I am saying it will be better if there can be alternative, but if not, I would rather not having this than having it.

[SCLeoX]

@mbrowne However, if you think about it, most of other proposal will not have any problem if any average developer can vote. On the other hand, I am almost certain that this # thing will have a hard time passing 50%.

Yes, I understand there is technical difficulties, but shouldn't we try not to disrupt the overall beauty of JavaScript at the same time?

[slikts]

There is a deeper ugliness in not being able to hide implementation details while still taking advantage of delegation. It complicates API design and implementation and invites poor practices. This should outweigh the syntax just being unfamiliar.

On the topic of voting: it's a bad idea simply because it's so open for manipulation and reflexive reactions. What's needed is thoughtful consideration, not counting upvotes or downvotes or sloganeering.

[mbrowne]

@SCLeoX

However, if you think about it, most of other proposal will not have any problem if any average developer can vote.

I highly doubt that is true. I haven't been very much involved in discussions about proposals other than this one (and a little bit with decorators), but I'm sure people can give examples of other proposals where making decisions just based on the community's initial uninformed reaction would have been disastrous.

Regarding the ugliness, that seems to be the common reaction and the committee members have said they don't find it aesthetically pleasing either and would have preferred to use a more intuitive syntax if possible. (I seem to be in the minority; I never disliked it for aesthetic reasons since I appreciated the conciseness, which is kind of handy if you believe as I do that encapsulation is really important and that "private" should be the starting point rather than just making things public without thinking about it. But I understand why others don't like it.) Anyway, it's not as if the committee deliberately chose this syntax against the wishes of the community. As explained in the FAQ and in past discussions here, significant problems were found with every other alternative that was presented.

[hax]

@SCLeoX @jhpratt

Alternatives without # existed. Check https://github.com/zenparsing/js-classes-1.1

Classes 1.1 proposal is created and presented by: zenparsing who is one of the champion of this proposal but do not agree # solution, awb who is the editor of ES2015, Brendan Eich who you must know.

But classes 1.1 is rejected, mainly because not include "public field", and I believe that is a big mistake.

You could check whether you like classes 1.1 and check recent issues in the repo for further discussion.

[hax]

@littledan

How do you think we in TC39 should assess how the majority of the community will feel about a proposal once they try it out a bit?

Simple.

I'd like to invite you, or any other champion who can represent this proposal to the one of the biggest front-end and JavaScript conference in Hangzhou, China on Jan 6, 2019. You can introduce this proposal, and I would like to present classes 1.1 proposal, and let them vote. 😂

Or, if you think I use my mother language in China is unfair to you ... it seems you will go to Tokyo next month give a speech. Just ask the organizer invite me too. Remember my English is very poor, but I still like to have a try.

[littledan]

I'd be really happy to attend a conference in China and discuss these sorts of issues (even though I only speak European languages--sorry!). I'm a bit overloaded on travel right now, and was thinking to try to take it slow after the Japan trip, but maybe some time later in 2019 would be good. Is there another conference in China that you'd recommend (or I could attend this one in 2020)?

[littledan]

I'd also be happy to have a video call to discuss this topic further, if folks would be interested.

[hax]

@littledan

I'd be really happy to attend a conference in China and discuss these sorts of issues (even though I only speak European languages--sorry!).

I used to think English is one of the European languages, no? 🤣

I'm a bit overloaded on travel right now, and was thinking to try to take it slow after the Japan trip,

Do you like to recommend any other TC39 member like @bakkot , Jeff Morrison or Shu-Yu Guo for Jan 6, 2019 conf? Though I think you may be the best one. 😉

but maybe some time later in 2019 would be good. Is there another conference in China that you'd recommend

Some conferences have not started to arrange schedule, for example JS Conf China. I only know CSS Conf China will be in 2019-03-30 .

(or I could attend this one in 2020)?

I'm afraid it's too late, as current situation, it's likely you already push it to stage 4, and landed in browsers in that time. 😂

[hax]

@littledan

Yes, delaying the Babel implementation was definitely an error on my part in this proposal.

It's unfair that classes 1.1 do not allow to forward even stage 0, which just make it can't have Babel implementation.

[hax]

@SCLeoX regarding developers who would vote solely based on their initial reactions of finding it "ugly and weird", without taking the time to deeply understand the technical considerations, I am glad that just the average developer cannot vote (and just to be clear, I am not a member of the committee).

It's a dangerous assumption that the dislike of "ugly and weird" from average developers is pointless. I see it indirectly reflect the mental model of most people, which TC39 should consider when design syntax. Especially there are some alternatives which do not use #. On one hand, you treat the dislike of # as pointless, on other hand, you nitpick on the syntax of alternatives.

And, as my observation, the dislike of # is general, whoever he/she is newcomer, average, experienced or master!

At least 95% of the complaints about the syntax are coming from people who haven't really considered the technical issues involved, including those mentioned in the FAQ.

Well it's not very pleasant, but I hope all TC39 members should see it in another, more sympathetic way: most developers do not have the knowledge, experience, chance, power to design/evolve a programming language, and normally they just accept anything you give them and never complain. There are many other proposals, why they only came here? Because it's important to them, and they feel really bad and have no other way to feedback. I don't know how you get the number 95% , but I bet that even they read FAQ, there is 95% chance they will also complaint.

And it is said, when you see one cockroach in your kitchen, it already have hundreds. So you see one such complain here, there would be hundreds on twitter, thousands in private conversation. Think about it!

[SCLeoX]

Beside this classes 1.1 proposal, there are many other proposal being rejected due to much less significant issues or without any proper evaluation. For example, using this#x instead of this.#x. (https://github.com/tc39/proposal-private-fields/issues/39#issuecomment-237121552) The only reason it is being rejected is it "would be an ASI hazard if we later introduced a shorthand syntax of #x". To be more clear, the entire reason is established upon an assumption that if a shorthand is to be implemented. When @jamiter questioned why there needs to be a shorthand, @littledan responded: "Even if the shorthand didn't exist, I kinda like the obj.#x syntax". That is just straight up BS. Saying you prefer "this.#x" does not invalidate "this#x".

[mbrowne]

@hax Looking back and my previous comment, I regret that I didn't try to give it a friendlier tone. I know that in written discussions, honesty can be mistaken as meanness or condescension. As I have said in stronger terms on other issues, I think the committee did not communicate with the community as well as they could have. Even if they were really listening and seriously considering all the feedback they received (which I believe at least some of the committee members were, at least those who actively follow the discussions here), the community didn't get that impression. I think it's important to put it in context though, because in the past, the committee used a separate mailing list that I guess was public since its archives would show up on Google, but it didn't really seem like it (it looked mostly just like committee members talking to each other)...overall I feel like involvement with the community is much more open now than it used to be. After all, anyone with a github account can post comments here and someone will respond.

This open access is why I think it's important to discourage lots of uninformed comments and/or voting from people who have not taken the time to understand the deeper technical issues, even though I agree that most of that is coming from people who are just innocently trying to express their concerns. We are already all very aware that most people find the syntax ugly and weird when first encountering it, so more and more issues essentially just repeating that are not going to change anything and affects the signal to noise ratio. Can you imagine what StackOverflow would turn into if no one bothered to enforce their policies on questions and answers? Everyone's time is valuable, not just the committee's of course, and pointing people to the FAQ if it appears they haven't read it saves everyone time.

Also, it seems you missed the importance of the word "solely" in this sentence:

regarding developers who would vote solely based on their initial reactions of finding it "ugly and weird"

Well it's not very pleasant, but I hope all TC39 members should see it in another, more sympathetic way: most developers do not have the knowledge, experience, chance, power to design/evolve a programming language, and normally they just accept anything you give them and never complain.

You're right, the majority of developers don't have the background and/or opportunity (maybe just due to lack of time) to really dig into all the technical details and learn how to read and understand the spec, and understand the various tradeoffs being discussed. (Being mostly self-taught on things related to language design, I too find the spec hard to read.) This is why we have a committee, but on the other hand we need to be compassionate and remember how many millions of developers of all backgrounds will be affected by this, and it underscores the importance of developer-friendly documents like the readme and the FAQ (and hopefully a forthcoming document listing requirements and general justification of their prioritization for this proposal).

And it is said, when you see one cockroach in your kitchen, it already have hundreds. So you see one such complain here, there would be hundreds on twitter, thousands in private conversation. Think about it!

It's hard to know whether or not you are right about this. The other side of this coin is that usually the people who disagree the most are the ones who are most vocal. There could be just as many people who would be fine with this, even welcoming of it, even if it's not their favorite syntax. If this proposal moves forward as-is then the next task will be to explain more widely why the syntax was chosen. There are indeed good reasons that hopefully most people will understand when they read about it (even those who still wish the committee had prioritized things differently). It's not really a great test to just give a talk with a brief overview of this topic and assume that the audience really understands the ramifications if their immediate response would be to vote "no" on the syntax. OTOH, clearly other proposals including classes 1.1 could be viable, so I don't mean to be too dismissive of these reactions.

[hax]

@SCLeoX

Beside this classes 1.1 proposal, there are many other proposal being rejected due to much less significant issues or without any proper evaluation.

I agree!

For example, using this#x instead of this.#x. (tc39/proposal-private-fields#39 (comment))

Good catch.

The only reason it is being rejected is it "would be an ASI hazard if we later introduced a shorthand syntax of #x".

Actually this is not a big issue in practice. Just use this[no-newline]#x.

To be more clear, the entire reason is established upon an assumption that if a shorthand is to be implemented. When @jamiter questioned why there needs to be a shorthand, @littledan responded: "Even if the shorthand didn't exist, I kinda like the obj.#x syntax". That is just straight up BS. Saying you prefer "this.#x" does not invalidate "this#x".

You are right.

The main reason they prefer this.#x is the slogan: #x is new _x.

[hax]

@mbrowne

It's not really a great test to just give a talk with a brief overview of this topic and assume that the audience really understands the ramifications if their immediate response would be to vote "no" on the syntax.

No. It's a good test.

You are not introducing a very big feature, so if you can't explain and convince them it's a good proposal in 45 mins, you can never in the future.

Actually I think "this.#x is new this._x" is a good slogan, and I'd like to see @littledan or other to try, which may prove that my worry about community break is superfluous.

[littledan]

Actually this is not a big issue in practice. Just use this[no-newline]#x.

That's a technical fix, yes, but many people use method chaining like this:

foo
   .bar()
   .baz()
   .bing()

In this mode, if . is replaced by #, you run into the issue.

Anyway, I like .# because it reinforces that the hash is part of the name, rather than being an operator. I hope this makes it easier to remember to never leave it out.

[hax]

@littledan

In this mode, if . is replaced by #, you run into the issue.

Yeah you are right, though I think chain like foo#a()#b()#c() is rare. I crossed out my original sentence.

Anyway, I like .# because it reinforces that the hash is part of the name, rather than being an operator. I hope this makes it easier to remember to never leave it out.

Actually, I totally agree with you in this single point. I can agree many specific point in many concrete cases. But the problem is your premises of this proposal are too many, too related, which I believe, make the whole proposal weak, and hard to convince all (even you could eventually convince me). And it will just cause community break which I think what's "this is the end day of JS" in twitter really mean.

Here is your premises I can collect from all the threads:

1. semantics requirement of privacy solution, and impossible to Java-like syntax
2. must land public field now, even no strong evidence tell us public field is a must to have uptonow, even redefinition of property from base class is a footgun, even other OO languages just discourage public field usage, even js programmers never have chance to try the replacement (accessor wrap private state)
3. public/private field syntax duality is good, even the semantics very different, which cause issues
4. can't add keyword for any reason, because it will bring syntax storm due to the duality

Note 2, 3, 4 are very related.

With all these premises established, I could agree the best available form for private is this.#x. But,

• For point 1, I am not against it at all, but many try to challenge it as they see it's the reason of ugly #.
• For point 2, I strongly disagree.
• For point 3, I totally admit the good part of duality (aka. "this.#x is new this._x"), but the duality could be good only when point 2 establish. And the contradiction between "no java style" from point 1 with duality in point 2 just draw fire which I think you can never escape. And the ignorance of semantic difference could bring programmer (especially TS programmers) bad experiences when they do migration to JS real private.
• For point 4 (you may not admit), it makes proposals fragile and rigid, significantly reduce the design space of the syntax for all related and future features, which I think it's bad. And eventually programmers are just forced to use decorators to mimic keyword.

This is all I can say, and I think classes 1.1 keep point 1, solve 2, 3, 4: no public field (at least in the form of this proposal), so no duality, adopt keyword, eventually no controversial # which I think is good to the community and make the whole ecosystem easier to move to the JS native privacy solution.

[SCLeoX]

@littledan I do not see how

foo
  #bar()
  #baz()

having any problem. # is the new ..

It just means to access the private property.

[littledan]

@SCLeoX It would only have a problem if we adopted @hax 's suggestion where we prohibit line terminators before #.

[SCLeoX]

@littledan But why do we need to prohibit that...

this
  #bar()
  #baz()

will always mean this#bar()#baz() unless shorthand syntax (#bar()) is implemented. However, I don't think the original proposal mentioned anything about the shorthand.

[littledan]

If we do add the shorthand syntax, we can't change the meaning of existing programs at the time that we're going back and adding it.

[SCLeoX]

@littledan So just don't add the shorthand if shorthand is a problem. Anyways, my point is, proposal like this are ignored without proper evaluation. The reason against it is because it doesn't work if the shorthand is to be added while the person proposed it did not mention nor want to add shorthand in the first place.

And in my personal opinion, having #foo shorthand is horrible anyways. I can already see that many people will think it is a comment given that #!/usr/bin/env node is already used in Node.js, and that is a comment.

For example, just ask anyone who isn't family with JavaScript what will the following code do:

#!/usr/bin/env node
class Stuff {
  doThings() {
    #log('I am going to do things').
  }
  #log(msg) {
    console.info('[Stuff] ' + msg);
  }
}
new Stuff().doThings();

9/10 they are gonna say nothing because the log call is commented out.

At the same time, I do not think there is any chance that @ will ever be swiped with # since decorator is already widely used.

[Mouvedia]

Here's an excerpt of the slides shown at the latest TC39 meeting:

Everyone I've talked to sees # as reasonable when I explain it

Clearly they haven't read #100 or worse they are aware of it and disregard it deliberately.

[littledan]

@Mouvedia To clarify that wording on the slides (which I've now edited, and which I think I clarified in another thread), I meant, everyone who I've talked to in person about this has come around to this, once they understand the logic. In my experience, these threads on GitHub are a more lossy and conflictive medium than when talking directly with people in person.

[Mouvedia]

@littledan you brushed the subject in that presentation. If you were objective you would have made a list of all the admissible critics of the community. In short, that's like saying "yeah Iv got all the right answers but I am giving them only in person". You might be able to rebut each person separately but taken as a whole the problem becomes obvious and should have been reported before the committee. Now I don't wanna single you out in that comment, I just wanted to point out the current posture at the TC39: evasive and pushy.

The problems are undeniable check #150

[littledan]

you brushed the subject in that presentation.

Writing slides is hard--if things are too wordy, everyone would spend the whole time reading the fine print on the slide not be able to listen to the talk. I'm sure the committee is aware that there are many people in this repository that are expressing these concerns.

Now I don't wanna single you out in that comment, I just wanted to point out the current posture at the TC39: evasive and pushy

I'm very concerned about this, and that's why I'm trying to do more outreach earlier in the TC39 process, so we can make sure to take everyone's point of view into account when making decisions. One effort is outreach group calls, which you can read more about at https://github.com/littledan/js-outreach-groups .

However, I don't think we should stop adding features to JavaScript just yet--the millions JS programmers out there deserve to have the incremental improvements in the language to meet their needs. I believe our stage process can be a helpful guide, if we interpret it to encourage the committee to collect extensive community feedback until Stage 3, make a strong call based on that feedback, and then pass the proposal off to implementers to make it reality.

If we don't have some stability at some point in the stage process before Stage 4, then we'll have a chicken-and-egg problem, and it will be hard to convince anyone to implement a feature.

[Mouvedia]

I'm sure the committee is aware that there are many people in this repository that are expressing these concerns.

That's great.

I don't think we should stop adding features to JavaScript

Me neither.

JS programmers out there deserve to have the incremental improvements

And the community is here to make sure it's the right ones and that the good parts book becomes larger.

[littledan]

@Mouvedia Agreed on all counts.

[rdking]

@littledan

@Mouvedia Agreed on all counts.

That's great and all, but isn't it clear that the current proposal is at dire risk of not being able to add to that book? I also agree with those counts. I just don't agree that what you're trying to feed the community isn't going to cause us all indigestion.

• Do we want private? YES
• Is the suggested syntax elegant? NO
• Can we live with ugly syntax? YES
• Is the suggested syntax or feature break the language? YES, and in several ways
• Is any individual one of those breaks significant? NO
• Are there too many breaks? YES
• Are there alternatives to this proposal already with, or capable of being altered to achieve more favorable results? YES
• Is TC39 willing to at least try? ??

That last one is the 10 million dollar question.

Honest question: How do you think we in TC39 should assess how the majority of the community will feel about a proposal once they try it out a bit? I want to figure out how we can improve the process for future proposals.

(I suggested that we require a transpiler implementation earlier in the process, but this suggestion was rejected by the committee; anyway, just an implementation isn't enough without a mechanism for collecting feedback.)

How about pushing what is now stages 3+ to stages 4+, and making stage 3 an open competition between all proposals that even have a chance of fulfilling TC39's requirements (which must be documented properly) as well as the public's expectations. Use this stage to implement all proposals that make it to this level in tooling. Newcomer proposals are welcome as well, as long as the stage 3 proposals are competing.

This will give the development community a chance to provide feedback to TC39 as well as a chance for TC39 to collect statistics from the tooling. At least with that, you'd have hard numbers instead of just intuition and feeling. At the end of stage 3, 1 of the proposals will be advanced to 4 in preparation for final inclusion in the ES spec.

How about we start this adjustment NOW and give both classes-1.1 and private-symbols a chance to compete.

[nicolo-ribaudo]

The competition between different proposal should ideally be at earlier stages (e.g. 1), like for the pipeline proposal (https://github.com/tc39/proposal-pipeline-operator)

[littledan]

Indeed, before reaching Stage 2, TC39 considered a variety of alternatives, including private symbols. We will never be able to say that all possible alternatives were considered in committee, but we also need to decide at some point whether to move forward.

[SCLeoX]

@littledan But you need to know that the majority of even very experienced developers are not going to pay full attention to what is going on in the committee, because they trust you guys will come to a good solution. However, this time, when they realized what you guys decided was not acceptable, they stood out. At this point, I think you guys really need to pause and take a step back.

And if the only reason you guys insisting moving forward is for the sake of moving forward, please, separate the private fields out from this proposal and move forward with public fields only.

EDIT: removed an ambiguous statement

[mbrowne]

@SCLeoX

I cannot stand you guys defending objections to private fields with the benefits of public fields.

I don't recall any instance where committee members did that.

[SCLeoX]

@mbrowne Somehow you totally misunderstood the meaning of that sentence. I admit that's somewhat my mistake. That sentence was suppose to be a follow up to the two sentences above.

What I was trying to say was that you cannot say we need to move forward so we have to accept private fields because that's using the benefits of public fields to overcome the problems with private fields.

(Just to clarify a little bit more, I was not trying to accusing littledan for intentionally mixing up two topics in order to get support for private fields. I sometimes organize my sentences in a really aggressive manner for no reason. I apologize.)

[mbrowne]

@scleo I didn't think you were trying to accuse @littledan of that.

I think the committee and other supporters of this proposal have made clear that it's important to release private fields because private fields are needed, not because the need for public fields somehow justifies bundling them with private fields and releasing both ASAP. That wouldn't make any sense. Private fields are just as important as public fields and probably more so...after all you can already create public fields in the constructor.

[mbrowne]

What is a consideration is that if private fields were removed from this proposal, it would probably be quite a long time before a follow-on proposal for private fields was shipped. There's a large segment of the community that is opposed to such a delay.

[rdking]

@nicolo-ribaudo @littledan

The competition between different proposal should ideally be at earlier stages (e.g. 1), like for the pipeline proposal (https://github.com/tc39/proposal-pipeline-operator)

It's fine that you think that, but it misses the point. The point of moving forward with multiple proposals until the last 2 stages is so that opportunities don't get missed due to an early dismissal of a proposal. The point of the approach I described is to develop multiple approaches in parallel. Then allow the community to explore each of the solutions to vet the one that has the most acceptable balance of features and trade-offs to the community. That's the one that gets to move to the last 2 stages. Scarce few will be able to complain in such a situation because options were available. Situations like where we're at now will be significantly less likely to happen.

[ljharb]

It's a reasonable claim to make that a proposal that's acceptable to the committee, but not acceptable to the community, might need further re-evaluation. However, if an alternative proposal is unacceptable to the committee, that alternative is a nonstarter - iow, it's not likely worth any further effort. Private Symbols have failed to achieve consensus in the committee multiple times, including recently, as has "classes 1.1". If you'd like to make an alternate proposal (ie, a full repo, not an issue thread or a comment) that hasn't yet failed to achieve committee consensus, and you can find a champion for it, I'd encourage you to do so! That this proposal is at stage 3 does not mean a competing proposal that meets all the criteria couldn't replace it - however, it probably does mean that the committee is pretty convinced that no acceptable alternative is forthcoming, and many years of suggested alternatives seem to support that position.

[rdking]

It's a reasonable claim to make that a proposal that's acceptable to the committee, but not acceptable to the community, might need further re-evaluation. However, if an alternative proposal is unacceptable to the committee, that alternative is a nonstarter - iow, it's not likely worth any further effort.

Calling it a non-starter is a disservice if there is a clear reason that can be remedied. Consider the classes-1.1 proposal. It was dismissed simply due to lack of public data properties. The point of that proposal was to implement private properties, not public data properties. Public could have been a later extension. This proposal was dismissed in exactly the manner @SCLeoX described. Even if public properties is a requirement, I've already found an adequate set of modifications to that proposal that will allow it to support public fields. So it's not like the proposal couldn't have been adjusted instead of being simply written off.

This is what I mean by developing different approaches in parallel. It also wouldn't hurt TC39 to formulate a clear set of requirement. I don't know how many times I asked to see this, just to hear that it's never been collected. How is anyone supposed to show you a better approach if you don't even know how to tell anyone what you expect? But I digress. The point is that early dismissal can cause you to essentially cut off your nose despite your face, or maybe paint yourself into a corner. No matter how you look at it, simply writing off proposals without an evaluation of whether or not the problems can be remedied is both dismissive and counterproductive. It may even be dangerous, causing us to march down a road that's riddled with unnecessary problems.

[rdking]

@littledan I would like to formally request that someone from TC39 compile the list of required features and expectation of any proposal that would be considered as even remotely having a chance to compete with class-fields.

I would also request that a similar list detailing the issues that led to the rejection of classes-1.1 be compiled.

My intent? Using those 2 lists, if it's even possible, I'll produce something that will meet all the checkboxes, likely based on classes-1.1.

Look, I get it. The class-fields proposal is being pushed through because of the high desire for private support in the language. I want it too. But let's be honest about what's being done here. This class-fields proposal is like a fillet-mignon from a 3 star restaurant being served to a starving man, except the steak was marinated in an ipecac-laced steak sauce. Not the best look, but not bad. Not too tough to process either, but when you get down to the small details, you wind up losing more than you gain just by consuming it. And you end up ruining the meal of others in the process as well.

It may be a goal of this proposal that private affects nothing outside of the lexical scope of the class, but the fact that there needs to be exclusions proves that this goal has failed. Once 1 popular library uses the class-fields version of private fields, I won't be surprised at all if the fallout that occurs afterward doesn't make TC39 revise their proposal process yet again.

Seriously, can those 2 requests be granted?

[rdking]

@ljharb There's something else wrong with this statement that I missed before.

It's a reasonable claim to make that a proposal that's acceptable to the committee, but not acceptable to the community, might need further re-evaluation.

That would be true if ES was a privately owned product, like Java and C# used to be. However, if the committee doesn't consider the effects of the proposal on the community, and the community decides to reject usage of the proposal, it becomes dead weight in the language. Is that acceptable? What's the point of releasing something that causes more problems than it solves? Certainly TC39 has more pride in its work than that.

[hax]

@SCLeoX

please, separate the private fields out from this proposal and move forward with public fields only.

Actually, in my opinion, public field has much serious semantic problem than syntax problem of private field 😭. And, after reading too much discussion, I just realize if we drop the public field proposal, we also solve almost all problems of private part 😉

[mbrowne]

@hax We've already been over why not including public fields would only be acceptable to part of the community; many people have legitimate reasons to want public fields (or rely on libraries that do) and it's not objectively bad to use public fields in the cases where they're appropriate. But regarding your claim, what actual problems would be solved by dropping the public fields proposal aside from helping to enable a syntax for private instance variables that you prefer?

[hax]

@mbrowne

We should reconsider what's the real motivation and use cases behind public field.

As I see, the main motivation of public field is component framework, especially React. Unfortunately, the design of React class-based component is flawed, even introducing public field can not fix it. The root mistake of React is it should never use class which is the tool for OO while React actually use FP and hate OO. React team know that and it's why they invent React hooks, though they will still keep supporting class-based component for a long time, we all realize it's not technical decision but social. Even without React hooks, React could be free of all "class issues" such as this, bind, super()... if it use factory pattern instead of class:

Rewrite Clock component sample in React official document to factory pattern

const Clock = React.defineComponent(({state, lifecycle}) => {

  state.init({date: new Date()})

  function clockTime() {
    return state.current().date.toLocaleTimeString()
  }

  function tick() {
    state.update({date: new Date()})
  }

  lifecycle.mount(() => {
    const timerID = setInterval(tick, 1000)

    return () => { clearInterval(timerID) }
  })

  return () => (
      <div>
        <h1>Hello, world!</h1>
        <h2>It is {clockTime()}.</h2>
      </div>
    )
})

We could use the motivation of React hooks to see how this factory-based design solve the problems of class-based design without the magic of hooks.

It's clear to me (and many who not have blind faith to React), the actual problem is the design of React, not the class feature of JS language.

Of coz, the guys support public field could argue public field could have other good use cases out of React. We could discuss them case by case, and we may find the similar problem like React case --- they just use class in wrong way! And even their usage of public field could be reasonable, we should notice that as https://github.com/tc39/proposal-class-fields/issues/151#issuecomment-431597270 shows, the frameworks/libraries has very conflict opinions on the very core semantic of public field. This is already a clear signal the public field proposal has something wrong.