Alternative: private class field symbols

[trusktr]

https://es.discourse.group/t/private-class-field-symbols/2262

The advantage over this proposal is that you have more control:

• if we do not export the symbol from a module, then we effectively have a private key for any classes in the same file, which is basically this proposal (except that the syntax of "private class field symbols" is available only in lexical scope of a class).
• if we export the symbol from a module, then we effectively have "protected" because any class that extends a base class can also use the symbol to access the same state (but the state is still not public because obj#[foo] would be a syntax error outside of a class

The syntax may be debated, f.e. this#[foo] or this.#[foo] or this[#foo], but I like this approach more because as the author of the Symbol, I would be able to make a choice: keep all the classes in the same file and not export the symbol (they are all "friend" classes then), or export the symbol as well as the classes (subclasses have protected access now).

In particular, a protected feature is needed for some real-world use cases, as described in that es.discourse thread with Custom Elements and ElementInternals. The ElementInternals API was designed in such a way that a class author could guarantee that the internals ould be private, but making them protected (which many people want) is very cumbersome.

So we need something that we can control, and the current private #var syntax seems much too restricted (to a single file).

[bakkot]

So we need something that we can control, and the current private #var syntax seems much too restricted (to a single file).

There's been discussion of being able to export declarations, with syntax for restricting where those exports are available.

The ElementInternals API was designed in such a way that a class author could guarantee that the internals ould be private, but making them protected (which many people want) is very cumbersome.

It's a little cumbersome, but not enough to warrant new syntax on its own, IMO. I don't want to reopen this discussion, just linking so other readers will have the context.

[trusktr]

It's WICG/webcomponents#962 (comment),

That's not a little cumbersome, that's very cumbersome, because for the internals to remain protected in subclasses, every subclass author has to apply the boilerplate.

Can you link to real-world examples where people like to write that type of code?

People will settle for "public" symbols before doing that. And firstly they may not even think about doing anything at all, therefore accidentally blocking subclass authors from accessing internals, but that ability to accidentally block subclass authors will exist even if "protected" is made easy (it still has to be opt-in, but the opt-in should be simple instead of verbose).

Simply put, we need protected to avoid all that unwanted dancing.

[ljharb]

"protected" (in the "access levels" sense) is not an idiomatic thing for javascript, nor will it ever be, so it's perfectly acceptable to me that it'll be cumbersome. I love this proposal, but if it makes "protected" easier, that's a huge mark against it, not for it.

In other words, I claim that wanting "protected" is incorrect, and we shouldn't ever have a goal of making it easier in JS.

[robbiespeed]

I like the simplicity of using symbols, mainly since it means no extra effort to allow export/import.

I also agree with @ljharb that "protected" shouldn't be a goal. Even if it was desirable I don't think it's achievable without considerable downsides.

The reason export/import is compelling for me is library level privates (without the need to resort to WeakMap and it's significant performance impact). One can develop a library and easily share the symbol across internal modules, then when publishing the library can be bundled and the symbol not included in the resulting exports. Alternatively if using a node compatible runtime the symbol can be exported from a module that is not part of the public exports in package.json.

Something that concerns me about using symbols though is it's potential for optimisation compared to private declarations. Imported symbols can be swapped to something else by the module that exports them so dynamic private access needs to leave the path open for the symbol to have changed or be replaced with something that cannot be used (this#[symbolOrString]).