Suspend releasing class-fields to stage 4.

[rdking]

Since we can't seem to make TC39 listen about the true severity of the issues in this proposal, at least suspend the release until there is some actual reality to the work-arounds that have been proposed for all of these problems. Class-decorators is still a stage 2 proposal. This means it is still subject to being tossed aside if an insurmountable issue is discovered. Only stage-3 seems to guarantee stage-4.

Meanwhile, in the current stage-3 proposal, many of the solutions for the numerous non-trivial problems in class-fields have been heaped upon class-decorators. Releasing class-fields to stage-4 without class-decorators is therefore a very good way to break the language. Anyone wanting to use class-fields would still have to use Babel to work around the issues. This is no different than if those same developers just used Babel to implement class-fields. There would be no advantage to releasing class-fields without class-decorators, but much harm can be done if class-fields is released alone.

[littledan]

TC39 doesn't really have power over when things ship. Chrome has already decided to ship public fields as in this proposal repository. I am not sure what action you want to be taken as a result of this issue.

[jhpratt]

@littledan TC39 could certainly request they hold back until major issues are at least resolved. Of course the Chrome team doesn't have to listen, but they could then be shipping what will become a nonstandard implementation.

I don't believe that we should be content to let the Chrome team ship something that isn't finalized, then likely come back and complain that the standards have changed and their behavior is different (or prevent the spec from changing at all). That's giving far too much power to one entity, and is not how a standards process should work.

[rdking]

@jhpratt Thank you. I literally couldn't have said it any better myself. (I may not have even been able to say it that well!)

[bakkot]

@jhpratt There has to be a point at which TC39 considers a proposal to be as ready to ship, at which point browsers can start implementing and shipping it. That point is stage 3. This proposal has been at that stage for a while.

[jhpratt]

@bakkot My understanding is that no one was supposed to ship until there were multiple independent implementations (stage 4). As far as I'm aware, that's not the case. And that's ignoring the many potential issues with this proposal (some of which I don't agree with) that the community has brought up.

[bakkot]

No, stage 3 is is the appropriate time to ship. Reaching stage 4 generally requires shipping implementations.

As far as I know pretty much all of the issues the community has brought up were brought up and discussed at great length before stage 3. I know not everyone is happy with the outcome, but that would be the case no matter what decision was made, including delaying another year (or another decade) while we rehashed the same topics.

[littledan]

OK, I think we have clarified in this thread that the request is out of scope for TC39 to act on, so closing the issue.

[rdking]

@bakkot Shipping implementations should only mean that the code is present and can be enabled, not that the code is the default. Stage 4 is when the proposal is finalized in terms of semantics. No one should shipping unflagged versions before that point because it would mean production code can be created before Stage 4 has been achieved. What would happen if some catastrophic flaw were to be found with unflagged versions and production code in the wild, but without Stage 4 approval?

[rdking]

@littledan

OK, I think we have clarified in this thread that the request is out of scope for TC39 to act on, so closing the issue.

Unfortunately, the only thing that has been clarified is TC39's stubborn reticence toward taking unpopular actions despite their prudence.

[littledan]

To clarify https://github.com/tc39/proposal-class-fields/issues/203#issuecomment-451637182 , TC39 takes it on a case by case basis whether the implementation needs to be unflagged to "count".

[ljharb]

@rdking then it's fixed. SharedArrayBuffer was stage 4 and shipping unflagged in many browsers, and a security issue was found - and every browser immediately removed the feature. Part of it's since been renamed, even ("wake" to "notify", iirc). Being stage 4 does not mean no changes can be made - it means that the committee, which includes browser vendors who have shipped the feature - is confident no such flaw is likely.

[rdking]

@littledan

To clarify #203 (comment) , TC39 takes it on a case by case basis whether the implementation needs to be unflagged to "count".

Do you really wanna go with that? Is it really your intention to say that the rules TC39 uses to decide what constitutes an "implementation" vary in an inconsistent way? Are you really wanting to tell the entire community that "the process" is so flexible as to be unpredictable? That's what you've just done. Are you aware of what you're saying?

@bakkot @littledan I'm trying my best not to let myself become completely disillusioned with TC39 and its practices. Please help me here.

Many of the "solutions" to the issues repeatedly posted in these threads has been to use decorators. Decorators is still a Stage 2 proposal. What happens if an unrecoverable flaw is found in the decorators proposal between now and Stage 4? The proposal will never be released, right? Wouldn't that mean that all the promises of solutions for the problems in class-fields would never come to pass and we'd be stuck with that?

My understanding has been that the major issues people have been raising that have decorator solutions. But if that falls through, then you have no solutions for those issues. Re-evaluate class-fields and it's problems in the context of no decorator proposal. Can you still say it's worth it? If you can't, if you ask the people who are currently ok with class-fields whether or not they'd still be ok if decorators wasn't in the pipe, and they're not ok, then guess what? You now have a veto-able proposal that has catastrophic flaws.

[ljharb]

@rdking yes, that part of the process is so flexible as to be unpredictable. Do you want us to be dishonest about it?

[rdking]

@ljharb Don't get me wrong. I'm very much pleased by your continued honesty. I'm just horribly dismayed by the fact that such an unstable process is being used to define the nature of a language with increasing importance. Regardless of whether or not Stage 4 is revokable, the fact that something like this can reach Stage 4 when its already known to be damaged is the problem. Compound this with the fact that the solutions for the worst parts is dependent on a proposal that will not be released concurrently or in advance of the borked proposal, and you're basically admitting that its perfectly ok to break the language. Just follow the logic.

[bakkot]

Do you really wanna go with that? Is it really your intention to say that the rules TC39 uses to decide what constitutes an "implementation" vary in an inconsistent way? Are you really wanting to tell the entire community that "the process" is so flexible as to be unpredictable? That's what you've just done. Are you aware of what you're saying?

Yes. But generally speaking, only small features are allowed to go to stage 4 without unflagged implementations. For large features like this, it's quite predictable: stage 4 cannot be reached without at least two of { Safari, Chrome, Edge, Firefox } having shipped unflagged implementations for a while.

I don't think it really ought to be surprising that a design processes carried out by humans is not totally rigid.

Re-evaluate class-fields and it's problems in the context of no decorator proposal. Can you still say it's worth it?

Yes. I know you disagree; let's not rehash that conversation again. But also, I and I think the rest of TC39 is pretty confident that decorators are technically feasible and will be part of the language, whatever our personal feelings about them.

Regardless of whether or not Stage 4 is revokable, the fact that something like this can reach Stage 4 when its already known to be damaged is the problem.

This is the core disagreement. This proposal is not "known to be damaged", or it would not have reached stage 3 and browsers would not be implementing it. You and several others disagree with certain of its design decisions and tradeoffs taken. That is not the same thing.

[Igmat]

You and several others disagree with certain of its design decisions and tradeoffs taken. That is not the same thing.

I wasn't joining this (and a lot of others) proccess related conversations, but I really tired to be treated as small but vocal group (c) @ljharb. Do you really think our opinion, arguments and activities aren't backed by some bigger community?

[littledan]

It doesn't seem like we're talking about class fields anymore. I want to say, this isn't the appropriate place to have these broader process discussions, but I don't have a good suggestion where we should discuss TC39 process with the community. I'll raise this meta-issue with TC39 management for advice.

[bakkot]

@Igmat, forgive me, I don't mean to imply that there are not many people who agree with you. I know there are.

[zenparsing]

For those critiquing our process: given our process as documented here what specific and concrete suggestions do you have for improving it?

[Igmat]

@zenparsing external feedback is repeated few times over that document. But there are no definition of such thing. So, I think, there are few important questions we have to answer:

1. What is included in external feedback (opinions told directly to committee, github comments, twits, third-party polls, etc.)?
2. How do we evaluate, prioratize and assess this feedback?
3. What actions should be applied when committee's opinion isn't shared by external feedback after collecting and properly assessing it?

Having answers to this questions will also help me to properly involve russian-speaking community, which I'm trying to do right now with help of @littledan and my employer (you may track the progress in https://github.com/littledan/js-outreach-groups/issues/6)

[littledan]

One thing which may be cross-cutting: if you want to help with a proposal in any way, get in touch with the champion and talk it over. Some champions may feel like their proposal is at a stage where it needs broad feedback, and your community work will be very helpful; others may feel like the proposal is either too early or too mature for that to be helpful. Sometimes the champion can give more context about what's going on with a proposal, and what open questions they need help resolving.

[Igmat]

@littledan even though your answer is usable, it doesn't provide us with answers to my questions.

I believe, that existence of some concrete answers to question 1 and 2 at the time when I was creating my article and poll which I made with it in Russian-speaking community (you may found related discussion in #162) much more valualbe. This also applies to @hax's #180 and @rdking's #194, because they were trying to provide you with something concrete.

At the same time answer to my 3 question is critical. Depending on it we may not waste our and your time (e.g. committee will do nothing even if a lot of negative feedbacks are collected), or we may not loose faith in standartizing process when something goes in a way we don't share (e.g. committee will suspend/revisit/move to earlier stage if a lof of negative feedbacks are collected). Sometimes, I think that I waste my time working on things like Membrane for Symbol.private, because it doesn't seem that anybody cares about, even though this issues is frequently raised when we're talking about alternatives

[littledan]

Well, there was discussion in this repository raising doubts on the method of presentation/article explaining flaws + poll. I can understand if you are concerned about these issues and trying to collect evidence to reverse the decision, but this is a little different from the optimal case of working with the champion in ways that everyone agrees are helpful.

I honestly look forward to working with you on collecting feedback on earlier proposals. I think in these future cases, you won't be facing these unfortunate contradictions.

[rdking]

@bakkot

I don't think it really ought to be surprising that a design processes carried out by humans is not totally rigid.

Nobody's asking for total rigidity. I'm simply expecting a reasonable level of predictability. The unexpected will remain so, but there should be a clear and fast definition for what the state of things should be before they're released. TC39's process apparently lacks that.

You and several others disagree with certain of its design decisions and tradeoffs taken. That is not the same thing.

OK. I'll grant you that. Replaced "damaged" with "containing many issues of debatable severity".

@littledan

It doesn't seem like we're talking about class fields anymore.

Well, you're half-right. The problem here is that the nature of the process determines whether or not the request I'm making is even remotely reasonable. It is clear that class-fields has issues. It is clear that TC39 thinks of these issues as acceptable trade-offs. It is clear that many in the community think of these issues as unacceptable trade-offs. It appears that TC39 thinks some of these trade-offs are acceptable because the decorators proposal offers a potential solution.

What I want TC39 to understand is that some of the issues we of the community find unacceptable are among those issues that can be solved via decorators, yet the decorator proposal, regardless of how "hopeful" it looks, is not ready for production and subject to change at any time between now and then. Some of these changes may completely remove its usability as a solution for the trade-offs. This is a problem. However, at present, from the words in this thread, it doesn't appear that it is a problem you(TC39) deem significant enough to address.

"To err is human." All we're asking is for you to "err on the side of caution." I posted my article on Reddit, and asked for opinions. From what I've seen, there's little to no overlap between the posters there and the ones here. Yet, so far, there's a 90% disapproval of the current proposal. This is the 3rd time something like this has been done. What will it take before the community's voice can be heard as loud in the board as the library vendors, engine makers, and company stake holders? It's the community at large that will suffer if this proposal turns out to be a misstep.

I've all but given up on hoping that this proposal will be dropped. Can I at least hope that it will not be released without the ability to work around these issues?

[MichaelTheriot]

For those critiquing our process: given our process as documented here what specific and concrete suggestions do you have for improving it?

Quick thoughts...

• Community should participate in selection of reviewers (somehow)
• External feedback should weigh more after widespread familiarity

Reviewers Anyone can be a reviewer and submit feedback on an in-process addition. The committee should identify designated reviewers for acceptance during the “draft” (stage 2) maturity stage. These reviewers must give their sign-off before a proposal enters the “candidate” (stage 3) maturity stage. Designated reviewers should not be authors of the spec text for the addition and should have expertise applicable to the subject matter. Designated reviewers must be chosen by the committee, not by the proposal's champion.

This proposal reached candidate stage, but appears to have 7:1 people against it. It seems evident that an accurate representation of the community during the review process was missing.

Stage 3 Acceptance Signifies The solution is complete and no further work is possible without implementation experience, significant usage and external feedback.

This suggests work is possible at stage 3; instead feedback is downplayed due to stage 3 acceptance. External consensus at candidate stage also appears to be irrelevant.

There appears to be no process in place to measure and handle adoption or rejection after familiarity.

[mbrowne]

I think the most important question right now is how much time will be allowed for collecting feedback (both from implementers and users) before this proposal advances to stage 4. As @MichaelTheriot pointed out, it's important that users get a chance to provide feedback after becoming more familiar with the details of the proposal, and preferably after actually trying it out as they are now able to do. Apparently this was supposed to happen in stage 2 (I think the decorators proposal is doing a better job of this, since there is a Babel plugin already). We can't go back in time, but the community should at least be aware of how much time we have to provide further feedback based on actual usage. (Of course, changing a feature that has already shipped in 2 or more environments is problematic, and anyone who has been paying attention here is aware that further changes to this proposal are extremely unlikely, but the stage 3 feedback window is still there for a reason...)

@rdking Regarding decorators, I think this is somewhat mitigated by the widespread use of transpilers. At least for frontend development, most people are already using Babel or TypeScript, and for decent browser-compatibility, the use of class fields will require the use of Babel for some time to come. And if you're using Babel, you can also use decorators (admittedly the decorators spec could still change in significant ways, but they're already quite usable).

[mbrowne]

In the future, I think it would also be great if the feedback collection process involved some empirical research on questions of ergonomics and developer expectations, as I mentioned at https://github.com/tc39/proposal-class-fields/issues/151#issuecomment-437671172. Obviously that involves more time and effort, but I think that kind of research would offer valuable insight that you can't obtain from discussions and polling alone (which is not to say that discussion isn't equally important). And a description of how this research is being conducted should be shared with the community, i.e. the process should be transparent.

[zenparsing]

To clarify, users in fact did provide significant feedback while this proposal was at stage 2.

[kaizhu256]

For those critiquing our process: given our process as documented here what specific and concrete suggestions do you have for improving it?

fixing the process is only part of the problem. fixing bias in the committee is just as important.

i perceive tc39 as biased (or even vested) towards solving c#/java/c++/etc. problems rather than javascript problems, which tend to be bigger-picture. as a former python-programmer, i was impressed by the vision-and-focus of those with influence on python's language-design. those folks were not afraid to say no to cool-features in other languages that made little sense (or presented risks) in python's problem-space.

and getting feedback from developers won't solve this bias. real-world developers oftentime have silo'd, small-picture agendas not completely aligned with employers in finding the simplest, most hassle-free way to ship javascript-products.

you should get more feedback from good technical-managers, and employer-side people frustrated with how more expensive/time-consuming javascript-development has gotten over past 4 years, without anything really tangible to show for it.

[mbrowne]

@zenparsing

To clarify, users in fact did provide significant feedback while this proposal was at stage 2.

Yes, and I'm sure that feedback was valuable and was taken into consideration. But it matters greatly how the questions were presented, and whether or not developers were aware of important details and consequences when they provided their feedback. That's why not only initial feedback is important, but also feedback "after familiarity". There's no visibility from the outside (that I'm aware of) into the committee's outreach efforts beyond the discussions on this repo, so it's hard to know whether or not the more private feedback collection suffered from any significant flaws. Maybe all of those users (including both library authors and general users) providing feedback were super informed. But at least in this github repo, I don't think everyone was aware of certain important things like [[Set]] vs. [[Define]] while the proposal was still in stage 2. Could the community have taken more initiative and become more informed about these issues, and more active in providing feedback at that time? Certainly. But I also think there's a lot of room for improvement in the process.

[mbrowne]

To be fair though, there was a public discussion about [[Set]] vs. [[Define]] at least as early as 2016: https://github.com/tc39/proposal-class-public-fields/issues/42. Only a handful of people participated in that discussion, and I don't think that many users were fully aware of the consequences of this semantic question at the time, but it was public.

[MichaelTheriot]

Regarding external feedback, I think it is helpful to keep a timeline of accessible, public events.

This is what I have been able to find publicly on the repos.

Date	Proposal	Action
2015-01-01	Private Fields	Created
2015-09-14	Public Fields	Created
2016-03-31	Private Fields	Stage 1
2016-07-19	Public Fields	Stage 1
2016-08-04	Public Fields	Stage 2
2017-05-14	Class Fields	Created at Stage 2
2017-06-08	Public Fields	Merged with Private Fields
2017-06-29	Private Fields	Merged with Class Fields
2017-07-27	Class Fields	Stage 3

It appears what is publicly available does not reflect the internal process.

e.g.

1. Private Fields never left stage 1
2. Class Fields merged Private Fields and Public Fields; presented at stage 2
3. Private Fields updated one month later to indicate merge
4. Class Fields reached stage 3 one month later

Assuming one loosely followed Private Fields, there was less than a month to challenge stage 1 to stage 3.

Just my thoughts, more consideration is needed so the typical developer can provide valuable feedback.

[rdking]

@mbrowne

Regarding decorators, I think this is somewhat mitigated by the widespread use of transpilers.

Both proposals are available via transpilers. I'm of the mindset that since one depends on the other as a means of providing work arounds for issues considered problematic by some segments of the community, it does not suit to release the problem before the solution. If a transpiler is ok for decorators, an incomplete proposal, then a transpiler is ok for the proposal whose usability is unnecessarily limited by the absence of the incomplete proposal.

@zenparsing

For those critiquing our process: given our process as documented here what specific and concrete suggestions do you have for improving it?

• Be as clear and as deterministic as possible with every step of the process.
• Define a process for determining the importance of a proposal. (Low, Normal, High)
• Define a time-limit following the submission of a proposal during which the importance of the proposal must be determined.
• Stop requiring a "champion" for Stage 0. Instead, use it to determine the importance and viability of a proposal.
• Only proposals that are not technically viable, or not deemed reasonable by the community should be eliminated from Stage 0.
• For proposals of High importance, more community involvement is required. So define a process by which wide community input can be gathered, and a time limit for such input.

There's more, but this would be a good start.

[lifaon74]

Following: https://github.com/tc39/proposal-private-methods/issues/10, sadly the tc39 committee is a little to much self oriented without listening the community... 228 likes vs 32 dislikes but still reached stage 4...

@littledan, @ljharb you're very active, answer questions, propose really important features (great job!) but NEVER accept community feedbacks... or give proper solutions to them. You push and force YOUR vision, most of the time it's smart and really good, bot not ALWAYS. Moreover, I dont see other committee members involved a lot on github, so its seems/feels like just a really few people control the future of the ecmascript and don't really give a f*ck about the community feedback... SAD 👎

[trusktr]

To be fair though, there was a public discussion about [[Set]] vs. [[Define]] at least as early as 2016

Also fair to say that GitHub has recently become a huge force in garnering community involvement in open projects. I'm willing to bet TC39 now has a larger community involvement thanks to GitHub.

And fair to say that thanks to the advent of the HUGE change that was ES6, which brought with it transpilers like 6to5 (Babel), we now more than ever have a means to propel the language into the future faster due to abilities to use language features before they're implemented in engines, and because of this the JavaScript language is arguably more liked than it ever was before.

And thus, you TC39 now have a more-rapidly growing community and more community involvement.

Yet, despite the very high number of upvotes on topics against this proposal, it seems like the standards committee is biased and not willing to consider the huge amount of community dislike.

Look at the number of upvotes on these topics for example: https://github.com/tc39/proposal-class-fields/issues/142 https://github.com/tc39/proposal-class-fields/issues/144 https://github.com/tc39/proposal-class-fields/issues/177

Many of the "reasons" in the FAQ are along the lines of "we don't want to confuse C++ developers" (how can you confuse a C++ developer?) or "Java devs might get scared when they try JavaScript" (I'm sure they know how to open up reference documentation, they'll be fine).

Let's choose the best options for JavaScript.

[zenparsing]

Let's choose the best options for JavaScript.

+1000000

[littledan]

I think there's a lot more we can learn from JS developers than threads like that. For example, developers outside of TC39 have driven the prioritization of the pipeline operator, and have led me to think more about (but not have any proposal yet for) immutable data structures.

Private is tricky. At this point, I am pretty confident that there would be significant concerns among many people in the community about any proposal that doesn't match how TypeScript works in syntax and semantics (even though that's infeasible technically, and even though certain subsets of people are happy with various other proposals). I don't think listening to the community should mean stopping doing work on important projects which are controversial; we have to make tough calls based on the input we receive. This hasn't been easy for me!

[trusktr]

I don't think listening to the community should mean stopping doing work on important projects which are controversial

True, and in fact the community wants private (and arguably protected too) yesterday! They want it, but want it differently for many varying reasons.

Seems like if we can get rid of some of the FAQ points that relate to confusing people from other languages, that we may get a better result.

[littledan]

Yes, it's apparent that, when discussing it directly, people express that they want various different things. However, it's pointing in all kinds of contradictory directions at once. We would need an FAQ for all of the disaffected constituencies either way, and I expect it'd be a similar size. There's no coherent proposal that meets everyone's goals, simply because many of these goals are in logical conflict with each other, and we've had to make tradeoffs.

I'd prefer if people didn't keep repeating the same point multiple times, in various different threads, especially when it's off-topic for the thread, just because the response wasn't what they might have wanted. It creates a lot of noise, and makes it hard for others who are making new points to get their message across. I'll start hiding these comments as "off-topic" if this pattern continues. @trusktr , you've started several threads to advocate for your various ideas; those would be some places to clarify the rationale for them, if you have something new to add.

[mbrowne]

Can anyone answer the question of when this proposal will be considered for advancement to stage 4? (I would say, "when is it expected that the committee will vote on it?" but it's a consensus process, not voting, so...)

BTW @lifaon74 Private class methods are still in stage 3; I'm guessing that was just a typo.

[littledan]

@mbrowne I hope we'll get to Stage 4 some time before autumn this year, but my predictions in the past have been a little optimistic :). We already have one implementation basically complete behind a flag (in V8), another implementation complete and out for review (in JSC) and a third implementation in progress (SpiderMonkey). I plan to propose class fields for Stage 4 once there are two implementations in a Canary/Nightly/Tech Preview build, unflagged there.

[lifaon74]

I agree there's many different opinions BUT it seems a majority is opposed to the current state of this proposal, seeing the huge amount of issues to cancel/update it and the like/dislike ratio associated with them. And even if 51% agree, 49% will be unhappy which is unacceptable if solutions can be found. A public survey could help, to expose the limits and gather community feedback.

You're clearly doing excellent job and most of the proposals are really good and useful. But this particular one is strongly controversial. It should take more time and take into account the ALL community feedback instead of forcing it. I guess the community is enjoyed about "private fields" but not with this current state, which miss a lot of wanted features that could be hard to implement later due early adoption of an "incomplete" proposal. For example: breaking proxies, missing decorators, missing "friend", missing "protected", missing "backdoor access" to a private property, etc... All of these points are critical but the committee avoid the question and do not provide any proper solution. The community provided some solutions to this problems but they seem ignored...

If so many thread are opened it's because the concern is real, and will impact millions of developers. Adding a method to an existing API is safe (ex: Array.flat) and simple to hack, but private field will lead to great changes. So it need to solve ALL the problems before its wide adoption.

[MichaelTheriot]

At least according to GitHub the proposal to add # sigil jumped stage 1 to 3 in just two months.

I am guessing this is not actually the case; is the history documented elsewhere?

I was hoping for a response, so I can be sure I am following the correct channels for future proposals.

[littledan]

I'm very sympathetic to the concerns that this proposal leaves things to be desired. That's why I am co-championing the decorators proposal, which I see as the most general solution to these problems.

[lifaon74]

So, what about including in the proposal a "friend" equivalent or an "backdoor" access (ex: Object.definePrivateProperty(class.prototype, propName, decorator), Object.getInstancePrivateProperty(instance, protpName) ?

These 2 functions will solve directly "friend" (king of), proxy (which may access private property though a backdoor), and allow developers to fix unmaintend libs. Moreover, it could help with decorators to create @Private properties; and allow private properties with old es5 class notation (with function and prototype). Without any impact on the current proposal.

I may suggest too (but less relevant or important), to rename the "private fields" to "scoped properties" (or at least, insist a little more on the scoped aspect vs the private aspect). The current name may confuse developers coming from other languages like C or Java, where the "private" keyword is used for a similar but different purpose.

[littledan]

We've spent a while thinking about how private fields and methods could fit into JavaScript's object model, and continually faced difficulties reaching a conclusion which preserved encapsulation and simplicity. We settled on a solution working a bit outside the box/MOP and base the semantics on WeakMap--it's as if private fields and methods are outside of the object, associated with it. Decorators provide these kinds of metaprogramming capabilities, but in a deliberately restricted way.

[lifaon74]

Always the same answer: "WE took the decision...". But the problems remain and no solution are provided. With this level of encapsulation you solve one problem but create dozen of others... That's a point why the community wants to cancel/rollback/delay this issue...

A simple Object.getInstancePrivateProperty(instance, protpName) seems for me to be a good tradeoff: we get private fields (developers want it) and we get control over external code in critical situations (developers want it too!).

[rdking]

@littledan My 2 cents: That design desugars very wastefully. There was no reason to "think outside the box" in this case. The only thing that needed to change was your perspective on that box. Keeping with the WeakMap-like model, the simplest solution that makes maximal use of existing engine code would be to put all private elements in a single object, seal that object, then store that object somehow (whether that be an internal slot, a WeakMap, or behind a private symbol is of little merit to the technique). Done this way, keeping with class-fields syntax, # means put the declaration on that object, and .# means access the member from that object. Take it 1 step further by moving the functions to the prototype of that object, and letting that object be created by an initialization function, and you've completely minimized memory requirements.

When I requested that TC39 analyze the "principle design" of class-members, I wanted for you to notice things like this. Some of the "trade-offs" TC39 keeps having to make comes from the simple fact that you're not allowing yourselves to make optimal use of the existing language structure. But once again, that's just my 2 cents.

[rdking]

@lifaon74 A few questions:

1. Do you understand that any kind of reflection on private fields turns them "soft private"?
2. Do you recognize that "soft private" is already provided for with Symbol (albeit not ergonomically)?
3. Would a more ergonomic syntax for Symbol solve your issue?

[littledan]

@lifaon74 It's not clear how to make that not work from outside of the class.