4 ms·

so static is `static` but private is `#` ? I wonder whats the reasonig behind it? `private` is already a reserved word in JS, why not just use it? https://www.

so static is `static` but private is `#` ? I wonder whats the reasonig behind it? `private` is already a reserved word in JS, why not just use it? https://www.w3schools.com/js/js_reserved.asp https://www.w3schools.com/js/js_reserved.asp

Klathmon 8y ago
I feel like i'm spamming this link every time the private fields stuff comes up, but take a look at the FAQ, it explains the reasoning behind it and why they didn't go with alternate options (like underscore, private, or others). I was against it at first, but after reading through that document, i'm on their side now. It'll be a small but useful addition in some situations, and it's scope is extremely limited. https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md https://github.com/tc39/proposal-class-fields/blob/master/PR...
- rinchik 8y ago
  Thank you for that link, will read it carefully. From the first glance it feels like an attempt to cover mess with a bigger mess: > this is already a source of enough confusion in JS; we'd prefer not to make it worse > Property access semantics are already complicated, and we don't want to slow down every property access just to add this feature. > [private x] in JavaScript this would silently create or access a public field Pardon me, but # as a declaration method of privates is an abomination.
  - notus 8y ago
    Yeah I have to agree with this. I'm getting this vibe from a lot of changes to JS lately. A mess designed to cover another mess and people almost blindly supporting the new mess just because there is some logical rationale for it.
manigandham 8y ago
There have been intense debates already for this decision. The fundamental reason is because Javascript has a messy "this.fieldname" requirement to access public fields so the only way to use a private field requires a symbol to denote that its private and not overlapping. I would've preferred the "this.private.fieldname" instead but # is what ended up winning.

Klathmon 8y ago

I feel like i'm spamming this link every time the private fields stuff comes up, but take a look at the FAQ, it explains the reasoning behind it and why they didn't go with alternate options (like underscore, private, or others). I was against it at first, but after reading through that document, i'm on their side now. It'll be a small but useful addition in some situations, and it's scope is extremely limited. https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md https://github.com/tc39/proposal-class-fields/blob/master/PR...

rinchik 8y ago
Thank you for that link, will read it carefully. From the first glance it feels like an attempt to cover mess with a bigger mess: > this is already a source of enough confusion in JS; we'd prefer not to make it worse > Property access semantics are already complicated, and we don't want to slow down every property access just to add this feature. > [private x] in JavaScript this would silently create or access a public field Pardon me, but # as a declaration method of privates is an abomination.
- notus 8y ago
  Yeah I have to agree with this. I'm getting this vibe from a lot of changes to JS lately. A mess designed to cover another mess and people almost blindly supporting the new mess just because there is some logical rationale for it.

manigandham 8y ago

There have been intense debates already for this decision. The fundamental reason is because Javascript has a messy "this.fieldname" requirement to access public fields so the only way to use a private field requires a symbol to denote that its private and not overlapping. I would've preferred the "this.private.fieldname" instead but # is what ended up winning.