docs: update readme with syntax for private symbols #3
Conversation
| they behave similarly to regular symbols, but at this time there is no | ||
| actual reification of private symbols. Private symbols can only be | ||
| access through `base.#priv` syntax. | ||
| they behave similarly to regular symbols. |
There was a problem hiding this comment.
I don't plan to introduce reification in this proposal. That'll be left to decorators. (I think only having small changes to the class-fields proposal will be easier to get through committee, and there is no reification of PrivateName included in the current class-fields)
|
|
||
| ```js | ||
| class Example { | ||
| #foo = 1; | ||
| private #foo = 1; |
There was a problem hiding this comment.
Ditto small changes only. You might be interested in following https://github.com/bmeck/proposal-private-declarations.
| ## Changes | ||
|
|
||
| ### API | ||
| Added new method to global `Symbol` built-in object for creating "private" |
| Added new method to global `Symbol` built-in object for creating "private" | ||
| symbols: | ||
| ```js | ||
| const privateSymbol = Symbol.private('private symbol'); |
There was a problem hiding this comment.
A minor goal is to only have private #x syntax, since Symbol.private could be monkey-patched to leak the privates.
|
So, correct me if I'm wrong. Should I move my works related to declaring symbols and shorthand syntax to https://github.com/bmeck/proposal-private-declarations repo? Both |
@jridgewell, I hope that I properly understood your thoughts in #1 (comment) and #1 (comment).
In order to keep it minimal, I left only
privatekeyword and what it needs, everything else will be provided in separate repos as follow-up proposals.Since you said, that it also should be discussed in
class-fieldstoo, should I create issue there?