The following is a bit of a rant, but summarizes my thoughts on the current state of ES classes.
I think it might be helpful to look back in time to before we had a usable ES2015 class syntax. Every previous attempt to create a class syntax failed because different players all wanted different things from classes. Attempts to create a "whole" class design covering all major features inevitably left some players dissatisfied.
I believe that we find ourselves in that same situation today. Every player's "pet" feature is covered under some proposal:
Private fields
Private methods?
Static private fields?
Public properties syntax
Decorators
Each proposal carries with it an implicit set of value-judgements. For example, the private fields proposal places a high value on performance and conceptual elegance, whereas the public properties syntax puts a premium on ergonomics (e.g. the desire to have subclass initialization customization without the need of a constructor specification). Decorators are largely motivated by overrepresented special interests (framework authors).
They are all stuck at Stage2 and it appears that none of them can move forward without all of them moving forward. In other words, it's the same old logjam.
I don't believe that the current "union" approach to class design will work. It creates a mess with little conceptual integrity. This proposal does an admirable job of trying to sort out that mess but ultimately falls between the stools because it sacrifices the DWIM (do what I mean) spirit of ES2015 classes. The user/reviewer should not have to simultaneously think about both the OOP intent of the class and also the JS-object-level implementation of that intent. By requiring the own specifier, that's exactly what we're asking.
The whole situation has been complicated by transpilers. Not only do we have to contend with the set of expectations that come from traditional OO languages and JS itself, we now have to contend with the set of expectations that come from TypeScript and Babel plugins.
At some point I think we're going to realize the logjam for what it is and back off on all the bells-and-whistles. Decorators are just not good for the language (and have annexed valuable lexical territory). Public properties don't carry their weight. "Private methods" and "static private" are confusing and sketchy. We have to keep classes simple, and the only way to do that is to jettison the fluff.
The following is a bit of a rant, but summarizes my thoughts on the current state of ES classes.
I think it might be helpful to look back in time to before we had a usable ES2015 class syntax. Every previous attempt to create a class syntax failed because different players all wanted different things from classes. Attempts to create a "whole" class design covering all major features inevitably left some players dissatisfied.
I believe that we find ourselves in that same situation today. Every player's "pet" feature is covered under some proposal:
Each proposal carries with it an implicit set of value-judgements. For example, the private fields proposal places a high value on performance and conceptual elegance, whereas the public properties syntax puts a premium on ergonomics (e.g. the desire to have subclass initialization customization without the need of a constructor specification). Decorators are largely motivated by overrepresented special interests (framework authors).
They are all stuck at Stage2 and it appears that none of them can move forward without all of them moving forward. In other words, it's the same old logjam.
I don't believe that the current "union" approach to class design will work. It creates a mess with little conceptual integrity. This proposal does an admirable job of trying to sort out that mess but ultimately falls between the stools because it sacrifices the DWIM (do what I mean) spirit of ES2015 classes. The user/reviewer should not have to simultaneously think about both the OOP intent of the class and also the JS-object-level implementation of that intent. By requiring the
ownspecifier, that's exactly what we're asking.The whole situation has been complicated by transpilers. Not only do we have to contend with the set of expectations that come from traditional OO languages and JS itself, we now have to contend with the set of expectations that come from TypeScript and Babel plugins.
At some point I think we're going to realize the logjam for what it is and back off on all the bells-and-whistles. Decorators are just not good for the language (and have annexed valuable lexical territory). Public properties don't carry their weight. "Private methods" and "static private" are confusing and sketchy. We have to keep classes simple, and the only way to do that is to jettison the fluff.