Is it a problem that the 2 decade old S.O.L.I.D. principles are too easily violated when using private fields? For quick reference
Single-responsibility principle - A
classshould only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.
Open–closed principle - Software entities should be open for extension, but closed for modification.
Liskov substitution principle - Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface segregation principle - Many client-specific interfaces are better than one general-purpose interface.
Dependency inversion principle - One should "depend upon abstractions, not concretions."
The 1st problem is with the open-closed principle. Given a base class with private fields, admittedly, the class is suitably closed to modification when the core details are maintained through private fields and private functions. However, under those circumstances, there is no suitable means of subclassing the base class in a way that keeps the code DRY. In order to not violate the open-closed principle when the subclass would normally need to modify various values contained in private fields (usually done in other languages via the "protected" mechanism), ES code will instead be relegated to duplicating all relevant functionality and modifying what is needed. This is a violation.
The 2nd problem is with the Liskov substitution principle. Extending a
class and using private fields in the subclass can violate this principle. If the base
class is contained in a library that makes use of Proxy, the developer of the subclass will be walking in a mine field trying not to "invalidate the correctness" of the resulting program. While the base
class would have no issue being proxied, subclasses containing private fields and overridden methods that access those private fields would definitely cause errors. This is a violation.
I have mentioned before that I believe there to be things that TC39 failed to consider, specifically where it concerns developer usage patterns. While I can agree that the new private fields are well suited to the philosophy of preferring encapsulation over extension, the problem is that preference does not mean "to the exclusion of". Sadly, it appears that due consideration for the proper use of extension was either not given, undervalued, or under-evaluated.
My question is this:
Were S.O.L.I.D. principles considered during the evaluation of the private-fields proposal, and if so, how were they evaluated?