denoland
Port TS "Private" Variables to JavaScript Private Variables
Is your feature request related to a problem? Please describe.
TypeScript's private class property modifier is only checked when you are using TypeScript and the encapsulation is lost through compilation. Furthermore, we're assuming that someone didn't cast something as any along the line in which "private" variables are not private at all.
Describe the solution you'd like
I think that it would be best if we migrate all instances of private class properties to using the ES6 Private Variable syntax (#___) to help mitigate the chances of users having unexpected bugs because they were using a property in their JavaScript (or any-typed TypeScript). Also, this would help stop even more important mass code breakages from libraries using these private variables irresponsibly and causing issues for their unsuspecting users.
Describe alternatives you've considered
n/a
I am willing to work on this.
Just to point out, private fields not "ES6". They are technically not even part of the standard yet. It is expected they will be part of ES2022.
Wholesale change/refactoring would be breaking changes where they exist, because even though they are "private" they are still accessible at runtime and people may have decided to access them. They should be taken carefully on a case by case basis, not something that should be done wholesale across the code base.
Just to point out, private fields not "ES6". They are technically not even part of the standard yet. It is expected they will be part of ES2022.
Oh, thanks for the correction.
Wholesale change/refactoring would be breaking changes where they exist, because even though they are "private" they are still accessible at runtime and people may have decided to access them. They should be taken carefully on a case by case basis, not something that should be done wholesale across the code base.
Ok, do you know if there are any places where it would be ok to port to private variables to start off with? Or is the possibility of breaking code too large?
I guess also my issue is that we modify the types / names of these "private" variables in updates so what is the difference between removing them as the code could have broken if we changed the property's name or type.
Wholesale change/refactoring would be breaking changes where they exist, because even though they are "private" they are still accessible at runtime and people may have decided to access them.
It seemed to me like this is exactly the misusage case that this issue intended to surface through breakage by preventing access.
@sno2 Is that correct? If not, why perform the refactor?
I feel like this issue should be resolved as the private identifier no longer exists in std as far as I can tell.
