51–60 of 81 posts
Where there was coffeescript to highlight functional features in JS in a time where most JS was imperative, maybe we'll see a language that takes the OO sugar away to, again, reveal the functional language that's underneath.
Earlier quoted context omitted.
Agreed. We already had solutions for inheritance, etc... using prototypes, which are more powerful than classic OOP. Now we're in sort of a mess hybrid thing where issues like this are mostly unsolvable in a clean way.
JS classes build on prototypal inheritance, they aren't an alternative mechanism. So you apparently either don't understand them, don't understand "classic OOP", or both.
The point was that the syntactic sugar isn't needed.
The 'class' sugar actually obscures the power of prototypal inheritance, and imho, discourages people from learning it - to their, and the language's, detriment.
Earlier quoted context omitted.
JS classes build on prototypal inheritance, they aren't an alternative mechanism. So you apparently either don't understand them, don't understand "classic OOP", or both.
Yeah, I've only been doing OOP for about 22 years, so I'm pretty new to it. The point was that the syntactic sugar isn't needed. The 'class' sugar actually obscures the power of prototypal inheritance, and imho, discourages people from learning it - to their, and the language's, detriment.
Yes it is. The success of CoffeeSCript is absolutely a validation that developers are more productive with syntactic sugar such as the class keyword, destructuring and many many other features.
Now nobody forces you to use them. So why complain? It doesn't make Javascript harder to read for you, quite the contrary.
Personally I'm not against classes, if someone prefers to use classes instead of prototype it's fine by me. What I don't understand is why the TC39 is pushing for classes and classic OOP instead of other more pressing issues. You can accomplish OOP with prototypes. IMO the lack of type checking is much more problematic. Flow and TypeScript are just adding a new layer of problems to an already convoluted workflow.
You realise JS classes are syntactic sugar for prototypes, right?
Classes shouldn't be a priority.
Earlier quoted context omitted.
Yeah, I've only been doing OOP for about 22 years, so I'm pretty new to it. The point was that the syntactic sugar isn't needed. The 'class' sugar actually obscures the power of prototypal inheritance, and imho, discourages people from learning it - to their, and the language's, detriment.
> The point was that the syntactic sugar isn't needed. Yes it is. The success of CoffeeSCript is absolutely a validation that developers are more productive with syntactic sugar such as the class keyword, destructuring and many many other features. Now nobody forces you to use them. So why complain? It doesn't make Javascript harder to read for you, quite the contrary.
So it is your opinion that the community and users shouldn't give feedback on the design and direction of the language they use every day? That's an interesting approach to openness.
Earlier quoted context omitted.
> The point was that the syntactic sugar isn't needed. Yes it is. The success of CoffeeSCript is absolutely a validation that developers are more productive with syntactic sugar such as the class keyword, destructuring and many many other features. Now nobody forces you to use them. So why complain? It doesn't make Javascript harder to read for you, quite the contrary.
> So why complain? So it is your opinion that the community and users shouldn't give feedback on the design and direction of the language they use every day? That's an interesting approach to openness.
Wouldn't it be funny if we see a resurgence of compile-to-js languages? If JavaScript keeps on piling up layers I could see people longing for a simpler, smaller language. Where there was coffeescript to highlight functional features in JS in a time where most JS was imperative, maybe we'll see a language that takes the OO sugar away to, again, reveal the functional language that's underneath.
0 - https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
Wouldn't it be funny if we see a resurgence of compile-to-js languages? If JavaScript keeps on piling up layers I could see people longing for a simpler, smaller language. Where there was coffeescript to highlight functional features in JS in a time where most JS was imperative, maybe we'll see a language that takes the OO sugar away to, again, reveal the functional language that's underneath.
FWIW the arguably ideal target for compile-to-web tech, WebAssembly, is adding some OO too [0]. 0 - https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
Seems like a pretty fair and well though out solution after reading the latest response by bakkot.
I read through the thread, and the proposal sounds crazy to me. 1. Members marked private being accessible from other instances of the same class [1] is counter to every other OO language I have used. What is the prior art here? Why depart from all conventions like this? 2. The # syntax is not extensible. If TC39 decides to add protected, internal, etc. modifiers in the future, what will they look like? We should be…
[2] This is addressed here: https://github.com/tc39/proposal-private-fields/blob/master/...