6 ms·

If you think that the # syntax for private fields needs to be improved, then go to JS Committee's GitHub Issues and give feedback about it: https://github.com/

If you think that the # syntax for private fields needs to be improved, then go to JS Committee's GitHub Issues and give feedback about it: https://github.com/tc39/proposal-class-fields/issues https://github.com/tc39/proposal-class-fields/issues There's at least three specifically about the #: https://github.com/tc39/proposal-class-fields/issues/177 https://github.com/tc39/proposal-class-fields/issues/177 https://github.com/tc39/proposal-class-fields/issues/149 https://github.com/tc39/proposal-class-fields/issues/149 https://github.com/tc39/proposal-class-fields/issues/142 https://github.com/tc39/proposal-class-fields/issues/142 Remember to be constructive or just give a thumbs up to comments you like.

guntars 8y ago
There were hundreds of comments against this, both constructive and otherwise, alas the committee knows better and will do whatever they want.
- deleted 8y ago
  [deleted]
- Ajedi32 8y ago
  I think the water is somewhat muddied by the fact that the committee actually _does_ know better than the vast majority of people in opposition, as evidenced by the many uninformed comments in this thread suggesting alternatives that are objectively untenable. This is not to say that there aren't other viable solutions which would avoid the use of the current proposed syntax, but how do you weigh the advantages of avoiding a subjectively "ugly" syntax against the many other, much more concrete concerns that the TC39 has to evaluate when choosing a proposal? Should "the reflexive reaction of many devs when they first see the feature (without taking any time to try it out) is that the syntax is ugly" just be an automatic veto? If not, how strongly should that concern be weighted? Should an otherwise inferior proposal be accepted instead merely because the syntax is slightly prettier? Ultimately, I think you need to have a person or group of people in authority who will look at all available options and make an informed decision, even over the objections of the uninformed majority. Right now, the TC39 _is_ that informed authority.
  - drinchev 8y ago
    The solution that TC39 voted is based on requirements that can only be satisfied by having the ugly `#`. Namely they voted for encapsulation / hard-private [#33] as well as comparing private properties of two classes [2], which as a result makes the only possible syntax the one with the `#`. Unfortunately this comes at the price that once browsers implement this it will become history ( same as the `with` statements [3] and `labels` with `continue` [4] ). Because of backwards compatibility these will never be removed. Maybe in 2022 TC39 will decide that "use static-type;" will be a mode, such as strict mode, where you can write statically typed JS ( great idea, btw ), where this proposal will make no sense. Another "use class-inheritance;" mode would also finally end the abuse of prototype inheritance with syntax sugar. In this future the `#` will be just a huge annoyance. #33 : https://github.com/tc39/proposal-private-fields/issues/33 https://github.com/tc39/proposal-private-fields/issues/33 2 : https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-does-this-proposal-allow-accessing-private-fields-of-other-instances-of-the-same-class-dont-other-languages-normally-forbid-that https://github.com/tc39/proposal-class-fields/blob/master/PR... 3 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 4 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/continue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - JeremyBanks 8y ago
      I can sort-of understand the desire for the values to be hard-private, but I think even that would be achievable without new syntax[1]. However, they also want the existence and names of the properties to be hard-private, which seems excessive. (And linguistically inconsistent with the choice of non-hard-privacy for symbols.) [1]: https://github.com/tc39/proposal-class-fields/issues/177#issuecomment-448292545 https://github.com/tc39/proposal-class-fields/issues/177#iss...
    - ksec 8y ago
      May be by actively making Javascript Shorter and uglier, to steer people away from it, and making JS a compiling target only? I mean whenever I see # I thought I am either on tweeter or the code was commented out.
- drinchev 8y ago
  There is even an issue [1] that counts the votes for stopping this proposal. IMHO "No solution" would be better than "bad solution" in this case. 1 : https://github.com/tc39/proposal-class-fields/issues/100 https://github.com/tc39/proposal-class-fields/issues/100
  - snek 8y ago
    If you don't want the solution to exist, why do you care what it ends up being? You won't use it. You have no horse in the race.
    - drinchev 8y ago
      Reading / maintaining / working with other people's code?
ricardobeat 8y ago
@gaardani that clearly will work, as evidenced here https://github.com/tc39/proposal-class-fields/issues/100#issuecomment-387180668 https://github.com/tc39/proposal-class-fields/issues/100#iss...

guntars 8y ago

There were hundreds of comments against this, both constructive and otherwise, alas the committee knows better and will do whatever they want.

deleted 8y ago
[deleted]
Ajedi32 8y ago
I think the water is somewhat muddied by the fact that the committee actually _does_ know better than the vast majority of people in opposition, as evidenced by the many uninformed comments in this thread suggesting alternatives that are objectively untenable. This is not to say that there aren't other viable solutions which would avoid the use of the current proposed syntax, but how do you weigh the advantages of avoiding a subjectively "ugly" syntax against the many other, much more concrete concerns that the TC39 has to evaluate when choosing a proposal? Should "the reflexive reaction of many devs when they first see the feature (without taking any time to try it out) is that the syntax is ugly" just be an automatic veto? If not, how strongly should that concern be weighted? Should an otherwise inferior proposal be accepted instead merely because the syntax is slightly prettier? Ultimately, I think you need to have a person or group of people in authority who will look at all available options and make an informed decision, even over the objections of the uninformed majority. Right now, the TC39 _is_ that informed authority.
- drinchev 8y ago
  The solution that TC39 voted is based on requirements that can only be satisfied by having the ugly `#`. Namely they voted for encapsulation / hard-private [#33] as well as comparing private properties of two classes [2], which as a result makes the only possible syntax the one with the `#`. Unfortunately this comes at the price that once browsers implement this it will become history ( same as the `with` statements [3] and `labels` with `continue` [4] ). Because of backwards compatibility these will never be removed. Maybe in 2022 TC39 will decide that "use static-type;" will be a mode, such as strict mode, where you can write statically typed JS ( great idea, btw ), where this proposal will make no sense. Another "use class-inheritance;" mode would also finally end the abuse of prototype inheritance with syntax sugar. In this future the `#` will be just a huge annoyance. #33 : https://github.com/tc39/proposal-private-fields/issues/33 https://github.com/tc39/proposal-private-fields/issues/33 2 : https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-does-this-proposal-allow-accessing-private-fields-of-other-instances-of-the-same-class-dont-other-languages-normally-forbid-that https://github.com/tc39/proposal-class-fields/blob/master/PR... 3 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 4 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/continue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - JeremyBanks 8y ago
    I can sort-of understand the desire for the values to be hard-private, but I think even that would be achievable without new syntax[1]. However, they also want the existence and names of the properties to be hard-private, which seems excessive. (And linguistically inconsistent with the choice of non-hard-privacy for symbols.) [1]: https://github.com/tc39/proposal-class-fields/issues/177#issuecomment-448292545 https://github.com/tc39/proposal-class-fields/issues/177#iss...
  - ksec 8y ago
    May be by actively making Javascript Shorter and uglier, to steer people away from it, and making JS a compiling target only? I mean whenever I see # I thought I am either on tweeter or the code was commented out.
drinchev 8y ago
There is even an issue [1] that counts the votes for stopping this proposal. IMHO "No solution" would be better than "bad solution" in this case. 1 : https://github.com/tc39/proposal-class-fields/issues/100 https://github.com/tc39/proposal-class-fields/issues/100
- snek 8y ago
  If you don't want the solution to exist, why do you care what it ends up being? You won't use it. You have no horse in the race.
  - drinchev 8y ago
    Reading / maintaining / working with other people's code?

ricardobeat 8y ago

@gaardani that clearly will work, as evidenced here https://github.com/tc39/proposal-class-fields/issues/100#issuecomment-387180668 https://github.com/tc39/proposal-class-fields/issues/100#iss...