zenparsing
Help me understand why this proposal exists
Sorry for the horrible title, I couldn't think of a good summary to these questions:
- What value does this add in comparison to current es6 classes?
- Why add a new -> operator?
- Why class initializers over already implemented constructors, which essentially do the same job?
- Why go with hidden as the modifier when almost every other OOP language implements the private keyword?
Help me understand why this proposal exists
https://github.com/zenparsing/js-classes-1.1/blob/master/docs/motivation.md
What value does this add in comparison to current es6 classes?
https://github.com/zenparsing/js-classes-1.1#goals
Why add a new -> operator?
https://github.com/zenparsing/js-classes-1.1/issues/19#issue-302500975
Why class initializers over already implemented constructors, which essentially do the same job?
Not sure what this question is asking? Is it about static initializers?
Why go with hidden as the modifier when almost every other OOP language implements the private keyword?
private is already used by TypeScript and various transpiler based language extensions including implementations of the current class fields proposals. We want to avoid syntactic conflicts with such extensions.
Also, the semantics of hidden are not really the same as private in Java, C++, C#, or TypeScript. Using difference keyword is a way to avoid incorrect semantic assumptions based upon experience with other languages.
CoffeeScript made breaking changes for ES2015. Any reason TypeScript should not be obligated to?
After all, is this not what private was reserved for?
@MichaelTheriot
CoffeeScript is not JavaScript, especially the syntax part, though it follow most JavaScript semantics. So it's ok CoffeeScript make any breaking changes to JavaScript, they already did.
TypeScript is the superset of JavaScript, which have to keep all JavaScript syntax and semantics, and add compile-time type system. This is the design goal of TypeScript. If TypeScript made any incompatibility (breaking changes) to JavaScript, they need to fix it. For example, old internal modules of TypeScript has been changed to namespaces even it's not a real incompatibility but only a concept confusion. So if we use private keyword in native JS, they eventually have to fix it (change to other keyword, or just drop their private). This will be very painful for the whole TypeScript community.
private is reserved from the first day of JS just because it's a Java's reserved word. But it doesn't mean we must use it for JS native private. private usage in TypeScript is much more close to private usage in Java/C# than hidden in class1.1 proposal or current private field proposal. So even TypeScript did not take it, it may be still not a very good idea to use it in JS.
At the end of the day ES2015 could have explicitly refused to break CoffeeScript but did anyway. I think this should be precedent for anything that compiles to JavaScript, not the other way around.