BEbenatkin·May 11, 2023Submission
What do you mean by “encapsulation” / “hard private”?
1 points · Open discussiontc39
proposal-private-fields
HTML2017–2023
tc39 / proposal-private-fields · Archived
proposal-private-fields
A Private Fields Proposal for ECMAScript
9Distinct people
9Mentions
0Explicit recommenders
316GitHub stars
What to know before exploring
What it is
A Private Fields Proposal for ECMAScript
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- tc39/proposal-class-fields · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year9 dated mentions
Observed mentions: 2017-08-03 18:30:46 UTC to 2023-05-11 18:36:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
9 sources> - # private... not sure why they didn't just use the "private" keyword, but I don't care. I almost always use TypeScript anyways
One of the reasons was to allow private and public fields of the same name, so that subclasses are free to add own public fields without accidentally discovering private fields of superclasses. There were many more considerations that went into the design: https://github.com/tc39/proposal-class-fields/blob/main/PRIV....
There was a heated debate about this and the choice of the # sigil back in 2015 at the time private fields were being designed: https://github.com/tc39/proposal-private-fields/issues/14.
In JavaScript and TypeScript features of the last 3 years> `_` would cause compatibility issues with existing JavaScript code, which has allowed `_` at the start of an identifier or (public) property name for a long time. -- https://github.com/tc39/proposal-private-fields/blob/master/...
In Implementing Private Fields for JavaScriptThis is all covered here:
https://github.com/tc39/proposal-private-fields/blob/master/...
In Implementing Private Fields for JavaScriptHere’s what they said in the proposal
https://github.com/tc39/proposal-private-fields/blob/master/...
In Implementing Private Fields for JavaScriptThe 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
Read the rest
`#` will be just a huge annoyance.
#33 : https://github.com/tc39/proposal-private-fields/issues/33
2 : https://github.com/tc39/proposal-class-fields/blob/master/PR...
3 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
4 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] While others have corrected you, just to be clear, this is something they addressed in the FAQ. https://github.com/tc39/proposal-private-fields/blob/master/...
[2] This is addressed here: https://github.com/tc39/proposal-private-fields/blob/master/...
In JavaScript TC39 implementing hashmark private class fieldsI think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 and other places, you'll see this massive push back from the community, yet the proposal is moving forward regardless.
In JavaScript TC39 implementing hashmark private class fieldsBackground for this proposal and discussion can be found in this repo’s README and additional docs:
https://github.com/tc39/proposal-private-fields
In JavaScript TC39 implementing hashmark private class fields