I love this proposal and what it aims to achieve, but it concerns me heavily how much of it depends on convincing people that this is both fundamentally not a class but is also still a class.
Many have made their opinions on classes very clear - they do not want to introduce object oriented programming into a dynamic language such as ECMAScript, and I can see how this would influence the decisions to avoid the class terminology.
However, I see many disadvantages to this.
For one - classes are becoming extremely powerful and many proposals aim to bolster their usability and desirability. ES has managed to implement them in a manner that still largely respects the dynamic nature of the language while also respecting the restrictions one wanting classical classes may wish to benefit from, and thus could lead to heavy misuse as a means to gain benefits of classes without using classes in name.
For two - the specifications highlight that these are still effectively classes and it’s likely polyfills will base their implementation on them anyway. This introduces a new concept on the back of an existing concept merely pretending to not be that concept.
Three, structs generally should not hold methods. Structs are a place to store data not mutate or interact with it. While some languages use patterns of storing pointers to methods in structs, they are not inherently a part of the struct themselves as they would be here.
I find it would be far more beneficial to instead introduce new keywords that modify the behavior of classes. Introducing a “sealed” modifier for classes establishes a keyword that indicates a modification to the behavior of classes that both has familiarity for those who have used other class based languages and conveys the idea of what’s going on better than struct as an alternative to class.
The other keywords in the proposal could still apply to classes, and syntax errors can convey the proper issues such as “shared classes must be sealed.” Additionally it opens the door to sealed being used elsewhere - the need to make objects immutable for example could leverage the sealed keyword bringing immutability to objects that may not be suitable for class based concepts.
I fear the introduction of a new data structure with its own unique name that is so identical to an existing data structure is a path towards the nightmare that drove Java to have negative connotations around it, and opens the door to concerning amounts of deviation - not being tied to classes, it could lead to a point where both must maintain identical functionality while being largely the same and the introduction of a class of bug where an issue in both is only fixed in one.
I can provide a few good examples that counter my opinions - for one, this can lead to rather lengthy declarations such as “sealed shared class Box extends Shape” but I think this only furthers the idea that this has a purpose and careful consideration must be taken for its use. For two, it could lead to pushback on use and integration of a great feature for safety and atomic memory but I see it more as an opportunity to get people to reconsider the fact that ES classes are not Java classes, not C# classes, but instead a carefully considered and well implemented idea of what it means for a class to be a class opposed to the definitions people typically associate with OOP languages that have arguably deserved criticism.
LIHUA919
commented
2 days ago
I love this proposal and what it aims to achieve, but it concerns me heavily how much of it depends on convincing people that this is both fundamentally not a class but is also still a class.
Many have made their opinions on classes very clear - they do not want to introduce object oriented programming into a dynamic language such as ECMAScript, and I can see how this would influence the decisions to avoid the class terminology.
However, I see many disadvantages to this.
For one - classes are becoming extremely powerful and many proposals aim to bolster their usability and desirability. ES has managed to implement them in a manner that still largely respects the dynamic nature of the language while also respecting the restrictions one wanting classical classes may wish to benefit from, and thus could lead to heavy misuse as a means to gain benefits of classes without using classes in name.
For two - the specifications highlight that these are still effectively classes and it’s likely polyfills will base their implementation on them anyway. This introduces a new concept on the back of an existing concept merely pretending to not be that concept.
Three, structs generally should not hold methods. Structs are a place to store data not mutate or interact with it. While some languages use patterns of storing pointers to methods in structs, they are not inherently a part of the struct themselves as they would be here.
I find it would be far more beneficial to instead introduce new keywords that modify the behavior of classes. Introducing a “sealed” modifier for classes establishes a keyword that indicates a modification to the behavior of classes that both has familiarity for those who have used other class based languages and conveys the idea of what’s going on better than struct as an alternative to class.
The other keywords in the proposal could still apply to classes, and syntax errors can convey the proper issues such as “shared classes must be sealed.” Additionally it opens the door to sealed being used elsewhere - the need to make objects immutable for example could leverage the sealed keyword bringing immutability to objects that may not be suitable for class based concepts.
I fear the introduction of a new data structure with its own unique name that is so identical to an existing data structure is a path towards the nightmare that drove Java to have negative connotations around it, and opens the door to concerning amounts of deviation - not being tied to classes, it could lead to a point where both must maintain identical functionality while being largely the same and the introduction of a class of bug where an issue in both is only fixed in one.
I can provide a few good examples that counter my opinions - for one, this can lead to rather lengthy declarations such as “sealed shared class Box extends Shape” but I think this only furthers the idea that this has a purpose and careful consideration must be taken for its use. For two, it could lead to pushback on use and integration of a great feature for safety and atomic memory but I see it more as an opportunity to get people to reconsider the fact that ES classes are not Java classes, not C# classes, but instead a carefully considered and well implemented idea of what it means for a class to be a class opposed to the definitions people typically associate with OOP languages that have arguably deserved criticism.