trusktr
commented
5 years ago Encourage the use of "best practice" use cases
New best practices may now be:
- If you're a framework/library author,
- do not use class fields. They may override user subclass accessors.
- do not use concise accessors. Users may unintentionally override them with class fields.
- If you're writing an application,
- look at the source code of your frameworks and libraries, not just the docs, to know if they use class fields or not.
- don't use class fields, as they may break frameworks/libs that you are using.
- don't make concise accessors, they may become useless if the frameworks/libs you are using change to class fields.
🤣
brianjenkins94
rdking
MichaelTheriot
ljharb
marlon-tucker
kaizhu256
nicolo-ribaudo
I think I've finally figured out how to word the 1 argument that everyone against this proposal has in common, that I haven't seen any evidence of being considered or argued in the past. I've been trying to make this argument over the past 3+ years with no success, likely because the wording was always directed toward some feature. Admittedly, TC39's stance on its decisions is unassailable for various reasons. So from that point of view, it's flatly impossible to get any of them to change their minds. However, what if I present the argument like this:
The core problem with this proposal, that precipitates all of the issues that are constantly being re-hashed to no avail, is that this proposal does not give adequate consideration to the most common use cases for the features being offered. This requires understanding not only the technical aspects of the design, but also the practical aspects of how it will likely be used by developers. While TC39 has done its best to provide us with a proposal that meets some here-to-for undocumented collection of requirements, it is at best questionable whether those requirements are in alignment with the practical needs of the ES developer community.
As it was explained to me at some earlier point in this proposal, the purposes of adding new syntax are to:
It's that 3rd position that raises an issue. TC39 is currently taking that statement to mean that no existing code base will be functionally disrupted by the existence of the new feature. From the standpoint of an ES developer, while helpful, this is neither a viable nor tenable stance. It may be better if TC39 could take that statement to mean that neither existing code bases nor existing programming paradigms will be needlessly disrupted by the existence of the new feature. Giving weight to how the majority of developers use the language is the important part.
Here's an example of the problems in `[[Set]]` vs `[[Define]]` from the standpoint of prioritizing how developers use the language.
--- For instance, in the `[[Set]]` vs `[[Define]]` debate, TC39's consensus was in favor of `[[Define]]`, their reasoning being that this makes clear the effect of initializing a field in a `class` definition. This, however, is in immediate opposition to how the language is currently used. When an object with a non-trivial prototype chain is created, assigning an initial value to a property of the object is first checked against the prototype chain since there may be a getter or setter. This is a non-trivial part of the prototypal design of the language. This is also something that every developer expects to be true. In all fairness, it is true that this only affects inheritance chains (especially ones containing accessors), but isn't that one of the major up-sides of using `class` in the first place? If there is no intention on using inheritance at some point, there is virtually no advantage in using `class` over a factory function. The worst part about this decision is that on the one hand, the choice has been made to allow initializers to run at instantiation time instead of `class` definition evaluation time. This leads directly to the misconception that a constructor is not necessary if it would only be used to initialize field values. This leads to the case where either one is left with needing to remember which fields can be assigned in the definition and which must be assigned in the constructor, regardless of whether or not accessors are used. This is truly a complication developers do not currently need to worry about. Trading in the need to have knowledge of the API you're extending for this added complication is definitely outside ES developer expectations, and a hard break in many common use cases involving inheritance. Encouraging the use of this feature is therefore essentially inviting hard to debug problems. ---I can provide an equivalent common use case summary for each of the major issues contained in this proposal. All of them are issues where inadequate consideration (despite the many years of discussion) was given to how developers are commonly using the language. If there is any room left for discussion on this proposal at all that is not essentially re-arguing the same points again, it is likely to be in this topic of how most developers actually use the language.