Suspend releasing class-fields to stage 4. #203
Comments
|
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. |
|
@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. |
|
@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!) |
|
@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. |
|
@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. |
|
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. |
|
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. |
|
@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? |
Unfortunately, the only thing that has been clarified is TC39's stubborn reticence toward taking unpopular actions despite their prudence. |
|
To clarify #203 (comment) , TC39 takes it on a case by case basis whether the implementation needs to be unflagged to "count". |
|
@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. |
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. |
|
@rdking yes, that part of the process is so flexible as to be unpredictable. Do you want us to be dishonest about it? |
|
@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. |
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.
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.
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. |
I wasn't joining this (and a lot of others) proccess related conversations, but I really tired to be treated as |
|
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. |
|
@Igmat, forgive me, I don't mean to imply that there are not many people who agree with you. I know there are. |
|
For those critiquing our process: given our process as documented here what specific and concrete suggestions do you have for improving it? |
|
@zenparsing
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 tc39/js-outreach-groups#6) |
|
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. |
|
@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 |
|
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. |
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.
OK. I'll grant you that. Replaced "damaged" with "containing many issues of debatable severity".
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? |
Quick thoughts...
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.
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. |
|
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). |
|
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 #151 (comment). 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. |
|
To clarify, users in fact did provide significant feedback while this proposal was at stage 2. |
|
@ljharb Not true about Proxy. I've already demonstrated that with user-land code included before any other library, I can fix the Proxy/WeakMap problem with less than 100 lines of trivial code (that's pretty-printed lines). I don't need the authors cooperation if I can directly interfere with how Proxy gets used. Where private fields is concerned, it wouldn't likely be the case that they've willfully chosen to not be proxy safe. Just like now, it usually happens inadvertently, because use of the code with a proxy wasn't considered during the design and testing. That's very different from willfully chosing. But your point remains true nonetheless. That being said, since Proxy-related issues were not on the list of issues TC39 pushed off onto the decorator proposal, your whole argument this time is kinda moot. |
|
What issues, to your mind, require decorators, but affect more than just the class author (who naturally wouldn't choose to use private fields without decorators in those situations)? |
|
The biggest 2 are the [[Set]] vs [[Define]] problem that breaks upstream and downstream inheritance, and the lack of "protected" support. Both of these issues affect both the library developer and the library user concurrently. If a library user inappropriately overrides a developer's field, that could break the base class in some unexpected way. The same problem happens in reverse. If there is no "protected" support, there's no way to constrain monkey-patching, so a change by the developer can hurt the user, while a big enough user can constrain advancement of a developer. In other words, one of the biggest reasons for wanting full encapsulation and hard privacy would be left unsolved. |
|
Just a side thought: I was just thinking about something. I don't think I want private fields at all now. If public fields, decorators, and pipelining released, without private fields, then there would already be a relatively easy syntax for creating and accessing private data. |
|
Thanks for the reply. I don't see how "protected" support plays into that - if you mean hard privacy, then yes, i'm very aware of the dangers caused by delaying native hard-private instance properties. As for Set vs Define, with the current choice of Define, decorators would be one way you could write a field that used Set, but you'd still have to remember to do that - lacking decorators, if you remembered, you'd choose not to use a field for that property and do the assignment in the constructor instead. I'm still not clear on why it would be harmful for "users who need Set" to do what they're already doing - assignment in the constructor - a bit longer, while "users do need Define" and "users who don't care which is used" could use fields? |
|
It's harmful because it encourages usage. " Hey world! TC39 has finally released a method of declaring instance properties in the class definition! They call them "fields".... blah, blah, blah." After all the waiting we've been doing to get anything at all like that, how can you be so certain that the vast majority of developers won't forget about the gotcha until it get's them? Remember, if it can be done, someone will do it. So why is a non-0 risk suddenly ok? |
|
Because in this case, it's unavoidable - whether we choose Set or Define, with or without decorators, there's always the risk of someone accidentally using the wrong semantics. As an aside, it's very off-putting when you try to weaponize my out-of-context quotes to make an unrelated argument. |
|
@ljharb It's not weaponization, but rather just a kind reminder of the standpoint you claim to hold when you appear to be contradicting it. Feel free to do the same for me if I contradict myself. It's not unavoidable. There are plenty of ways to avoid it. However, for various reasons that have been ground into atoms by discussions in these threads, TC39 refuses to avail themselves of those working, and based on pre-existing and proven concepts, methods. For instance, "only define properties on things you created". From this standpoint, it's fine for a constructor to write properties onto an instance of its class. That's the normal approach, right? It's also fine for a class definition to write things onto the constructor and prototype. That's also the normal approach, right? I'm not trying to re-hash the relative merit of that approach vs what was chosen. So please don't. What I'm saying is that your claim of unavoidability is invalid. |
|
@rdking, I think @ljharb's point is that sometimes the thing someone wants is [[Define]] and sometimes it is [[Set]], and sometimes they will do the wrong one by accident, and that is not avoidable. Rules about how to write code which amount to "they should stop wanting that" aren't really a solution. |
|
Allow me to paraphrase TC39's standpoint, but from the point of view of an outsider like myself: "Let's hurry up and release this issue-riddled proposal. There's a small percentage of the target developer audience that would appreciate having it sooner rather than later. It doesn't matter that the vast majority of the target audience will not be able to benefit from it, or that it will block various use cases if that small percentage happens to be releasing shared code, or that it doesn't really solve 2 of the target goals of the proposal due to lack of sharing provisions." @bakkot Believe me when I say that I realize this already. That's why when I broke down and included public fields in class members, I put in 2 different syntaxes. It makes no sense for there to only be 1, and the 1 chosen is the most technically damaging. I never once claimed that anyone should stop wanting a means to declare data properties in |
This seems like our core point of disagreement. I expect the overwhelming majority of the target audience will be able to benefit from this proposal. |
The target audience this proposal benefits will give a burden to non target audience who have to maintain later. Also can we have a section in the readme stating clearly who would belong to target audience? TS users definitely are not. Lib authors, application developers ? etc... |
|
@bigopon why are TS users not? It seems to me like many TS users would prefer "actual" privacy: microsoft/TypeScript#564 https://medium.com/@pagalvin/private-members-in-typescript-are-not-always-private-962fd220d749 https://stackoverflow.com/a/12713869/632724 etc. I can't find the source, but I've been told that "actual privacy" is one of the most requested TS features (hopefully someone from the TS team can confirm/clarify) |
|
@ljharb, but the way you've taken isn't the only one to achieve |
|
FWIW, I'm a TS user (and also a JS user) and I look forward to being able to create private fields in TS that are actually private at run-time. (I also would like it if TS had an option for properties declared using |
I do want to see it. TS users code is fully of fields behaving in |
You may be thinking of this comment. Though it's also pretty obvious if you follow the TS bug tracker, since there's a new issue about this once every couple months. |
|
@bakkot Thanks for the link. Then the next part to prove the claim "majority target audience" is to make sure who want private field aware that what they ask is |
|
Since the difference only matters if you have a setter (edit: or a Proxy) higher up the prototype chain, which is not a common pattern, it seems apparent that the vast majority of cases won't care which is chosen for public fields. |
|
@bigopon I don't think it really makes sense to talk about Set vs Define semantics for private fields? And for public fields, most of the time (i.e. unless there are accessors or proxies involved, or someone has frozen a prototype somewhere) they will have precisely the same semantics. |
|
@bakkot That side effect on public field is really the issue though. But I think I'll just be repeating the arguments that have been made and probably won't be able to put it better so I'll stop at this
|
|
@ljharb, @bakkot it seems that you underestimate how many libraries are going to be created (and already) with Proxy as main building blocks of their capabilities. And |
Given how entrenched TC39 is on its highly subjective and speculative opinions, I sincerely hope I'm wrong. |
|
For me a typical scenario of failure will be (pure example, versions and lib name are not relevant): 2019: I create an app for a big company with this libs:
2023: I need to update this legacy code from Angular 1.0.0 to 10.0.0. It's business critical. The new libs are:
Here come the big problem: I may patch this particular removed method for my legacy code by rewriting it in the Observable (v2.0.0) prototype (kind of polyfill) PROBLEM: the method call some private field ! At this point I'm stuck and cannot upgrade my code at all:
The only solution is to rewrite almost everything which is unacceptable (or doing a lot of pull request on unmaintened libs...). I predict that people will be hipped with private field, they'll use a lot of it without knowing the danger in the future and abusing of them. When developers will start to encounter this problem (and they will !) many time after they embrace libs using private fields it will be too late, they will strongly regret their decision. Sadly in any cases they won't be able to patch anything because the power is given to the author instead of the consumer (hard private). No backdoor means disaster in a few years. In one sentence: You'll democratize a very bad habit (unmaintenable code) |
|
@lifaon74 I anticipate that projects which want to preserve backwards compatibility with patterns like this will just not use the feature for those cases. Some projects, like Moment.js and Node.js, have already tried to make changes to certain implementation details, and rolled back those changes when they were found to be incompatible with their users' code. I expect that such constraints will be a barrier to adoption of private fields and methods. |
If that's the case, then something doesn't make sense. The main group TC39 has mentioned as wanting "hard private" is library and framework vendors. However, what you're saying here is that these very same groups are going to be the ones having the hardest time adopting this proposal. That almost sounds like you're saying you realize the technical limitations of this proposal doesn't fill the need. If the goal is encapsulated data that cannot be observed outside the class methods, and has no observable effects outside the class methods, then does this not imply that it should be possible to use this private data implementation in any way that the implementation allows for without side effects to 3rd party developers? What am I missing? |
|
The idea is to enable the use of private fields and methods precisely in order to enable libraries to avoid dependency on internals. If they already have a de-facto public API which includes things which should've been designed as internals, then it's too late. But maybe private could be used in certain targeted refactorings--something which is exposed publicly now as a data property could become an getter/setter pair in the future which accesses the underlying private data. |
That's a dumbfounding mindset. It's not too late. It's just a major version change. It's just my opinion, but the fact that TC39 is pushing a proposal that even in its own opinion won't be viable for what to me looks like the majority of its target use-cases for several years is just utterly disconcerting. In any case, it feels like the answer to my request is a simple "No." It doesn't seem to be possible short of building a time machine and allowing you to use it to show you the apparently unanticipated damage this proposal will cause. And without such hard evidence, you're not willing to alter your admittedly subjective views. So I relent. |
|
Thanks everyone, for your thoughts. It looks like this thread has been going in circles for a while. This thread will be locked for being unproductive (we have not been able to achieve an outcome) and the initial question that was asked has been answered. |
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.
The text was updated successfully, but these errors were encountered: