Renaming of proposal to "Hidden State" (or similar) · Issue #72 · tc39/proposal-private-fields (original) (raw)

This repository was archived by the owner on Jan 25, 2022. It is now read-only.

This repository was archived by the owner on Jan 25, 2022. It is now read-only.

Description

I wanted to open a new issue for this, as my comment is part of a closed issue with 631 other comments.

The relevant part is as follows:

Having read all of the comments, it's quite clear to me that there are two sides here, with two different sets of requirements:

1. The side that is looking for a somewhat low-level hard private state feature
   • Maximum performance
   • Maximum "security" (minimum exposure)
   • Syntax is less of a concern
   • Must support built-ins like Promises, etc. (for whatever reason)
   • Must work with today's JS – no significant platform changes or differences in look-up semantics
2. The side that is looking for a higher-level soft private state feature (visibility modifiers)
   • Performance is less of a concern (although obviously it shouldn't be awful)
   • It's quite okay for private state to be accessed in an indirect manner (reflection, etc.)
   • It's okay for outside code to know that private fields exist, as long as they cannot be accessed directly
   • Syntax is important, as is consistency with other languages, and the desired syntax would be private x; and this.x for access
   • Might not work in today's JS – some changes would be required

We appear to be going around in circles, and none of the proposals thus far check all of the boxes. The above might be the reason for that.

I've suggested this before, but I'll do it again: Why not support both as different features with different use cases?

• This proposal could be renamed to something like Hidden State
• It would be made clear that this is not related to the visibility modifiers in other languages (incl. TypeScript)
• The syntax could be made even less attractive (f.e. double-hash ##val, similar to @@iterator) as an indication of its low-level usage
  • It might even be good to use a completely different declaration syntax, to separate such state (f.e. #{ var1, var2 = 5 };)
• All of the requirements for side 1 could be met
• A later proposal could be introduced to cater to side 2
• As this is likely to require changes to property access semantics and/or a limited type system, it might well need to wait for JS to evolve as a language
• Hopefully in time, this feature will be feasible, and the requirements can be met in an elegant way
• In the meantime, we can use TypeScript or another transpiled alternative. A clean solution is better than a rushed solution.

It's going to be very difficult, if not impossible, to reach consensus without such a compromise.

I feel that the above would quite possibly satisfy both parties, while also helping to avoid any confusion or misunderstanding.