Accessing it outside its class body shouldn't be a SyntaxError.
It makes me wonder what would happen if they tried `counter[“#value”]`. Hopefully still an error, but also hopefully not SyntaxError, because it certainly isn’t one.
Public and private class fields
51–60 of 112 posts
Re: Public and private class fields
#52I am not sure it is possible any longer for JS to avoid getting larded up with a bunch of features from other languages, due to the popularity it has achieved. But one of the things I used to like about it was its relatively constrained feature set. (I would almost say simplicity, but some of the wackier aspects of the language prevent me from going that far.) Now we have things I’m not sure anyone even uses like Symbols.
(Please don’t tell me I can just constrain the code I write to the subset of features I care about. We all read more code than we write.)
Re: Public and private class fields
#53Here's the issue where dropping '#' syntax is being discussed:
https://github.com/tc39/proposal-class-fields/issues/177
Re: Public and private class fields
#54This is Exhibit N for the "the class keyword is ruining Javascript" prosecution. If you want a "private variable" you just use a closure. let incrementer = () => { let x = 0; return { value: () => x, increment: () => x++ }; }; It's like the OO people are determined to forget about the functional concepts that made JS great.
I was in the process of writing a reply that argued against this (mainly because it is not as readable as a class implementation), but I sort of agree with you as well. That said, considering how widespread JavaScript is at this point, I think it is in their best interest to cater to more than one programming style.
> That said, considering how widespread JavaScript is at this point, I think it is in their best interest to cater to more than one programming style.
No! Stop! Bolting 6 different programming paradigms into a language doesn’t make it easier to learn. It makes it harder, because every programmer who learns JavaScript needs to learn all of the tools of the language so they can read the code written by others.
More language features / paradigms make JS less accessible. It is a terrible idea if your goal is to help people learn JS.
Re: Public and private class fields
#55First, like the other commenters, I'm not in love with the perlish # syntax. I'm not sure why it was wise/necessary to add a previously illegal character as a prefix, rather than adding a "private" keyword, but I'm sure there's some reason. Second, the example affords an opportunity to rant about a pet peeve of mine. "Now ask yourself, how would you implement this class in JavaScript?" I wouldn't. Listen folks: unles…
Getters/setters are useful. E.g. maybe you had a class 'Box' with a field 'area'. Later you added fields 'width' and 'height'. What are you going to do? Change 'area' to 'getArea()' and break the API? Write extra code to ensure that you update area every time you change width or height? Or write a getter that returns width*height? I'd say getter is the cleanest option in many cases.
This is why languages with properties are fantastic. If you find that you would rather have a getter than a member variable, you just change it to a property. You get all the backwards-compatibility of getters without paying the development cost of them up front.
Re: Public and private class fields
#56This is Exhibit N for the "the class keyword is ruining Javascript" prosecution. If you want a "private variable" you just use a closure. let incrementer = () => { let x = 0; return { value: () => x, increment: () => x++ }; }; It's like the OO people are determined to forget about the functional concepts that made JS great.
That means that for every incrementer you create, you've also got to allocate two additional functions: value and increment. They have to be distinct objects, because `incrementer().value === incrementer().value` must yield false.
Debugging is also harder. When you're debugging and you find an incrementer somewhere else in your program (maybe somewhere unexpected), how do you know what kind of thing you have? All you can tell is that it's got a value and an increment method, so you've got to do a bunch of grepping over your source to find where it comes from. If it were a class instance you could ask instance.constructor.name to find out that it's an Incrementer, so you can grep for `class Incrementer`.
Yes, lambda can do everything, which is really cool to learn! But lambda isn't the ultimate. More specialized tools often carry benefits.
Re: Public and private class fields
#57Earlier quoted context omitted.
I was in the process of writing a reply that argued against this (mainly because it is not as readable as a class implementation), but I sort of agree with you as well. That said, considering how widespread JavaScript is at this point, I think it is in their best interest to cater to more than one programming style.
> That said, considering how widespread JavaScript is at this point, I think it is in their best interest to cater to more than one programming style. No! Stop! Bolting 6 different programming paradigms into a language doesn’t make it easier to learn. It makes it harder, because every programmer who learns JavaScript needs to learn all of the tools of the language so they can read the code written by others. More lan…
I agree with you, but if they are going to pick one paradigm to build new features for, it is certainly going to be OOP (for better or worse).
Re: Public and private class fields
#58If they were going to use a new syntax for private members, why not a minus sign: class { -privatefield }? At least there's some precedent for that, and it's already a token in the grammar which currently has no meaning inside a class declaration.
Also: another poster added that private members should just be closed over in functions. Well, I don't find it productive to condemn classes as as a concept, but if JS already has classes being syntactic sugar for a type of methods, it makes sense that private members would be sugar for closed-over variables also.
Re: Public and private class fields
#59To reiterate what others said, choosing an unusual syntax that is non-obvious motivated by a synthetic example to solve a problem already solved by many other languages in better ways almost raises the suspicion that we’re deliberately trying to make JS even worse... to kill it? Or is this just indicative of the process that got us to this mess in the first place?
A more reasonable policy for JS would be to (a) contain it - no more changes, no more extending its use outside of its current surface, (b) the development of an alternative approach that would - crucially - support competing languages so that we don’t get stuck in this way again, (c) gradually shrinking eliminating JS with a goal to complete retirement.
Re: Public and private class fields
#60First, like the other commenters, I'm not in love with the perlish # syntax. I'm not sure why it was wise/necessary to add a previously illegal character as a prefix, rather than adding a "private" keyword, but I'm sure there's some reason. Second, the example affords an opportunity to rant about a pet peeve of mine. "Now ask yourself, how would you implement this class in JavaScript?" I wouldn't. Listen folks: unles…
Getters/setters are useful. E.g. maybe you had a class 'Box' with a field 'area'. Later you added fields 'width' and 'height'. What are you going to do? Change 'area' to 'getArea()' and break the API? Write extra code to ensure that you update area every time you change width or height? Or write a getter that returns width*height? I'd say getter is the cleanest option in many cases.
> Write extra code to ensure that you update area every time you change width or height?
Unless I change width and height all the time, but only read the area very rarely: of course, and gladly so, since I much prefer that to fetching two values and making a multiplication for what could be a simple fetch instead. And don't get me started on code that uses a getter on a value that doesn't change in a loop. I don't find that stuff "clean" at all. Don't just ask how it looks in the editor, ask what it makes the machine do.