5 ms·
One important thing to note here is that this goes much further than `private` in TypeScript. The latter is purely a compile-time illusion. If you write `privat
by denisw 8y ago
One important thing to note here is that this goes much further than `private` in TypeScript. The latter is purely a compile-time illusion. If you write `private x`, your objects' x property is still publically accessible and modifiable as far as the JS runtime is concerned. any other. It‘s just the TypeScript compiler that gives you an error if you access x, and only if it happens to have the type information it needs to do so (if the object ends up in an `any` variable, all bets are off).
This means TypeScript's "private" properties also shows up in the return value of Object.keys() etc. So it‘s a pretty leaky abstraction.
This proposal, on the other hand, tries to solve the much harder problem of of bringing true private instance variables to JS. This means making it impossible to access these variables from outside the project. To do this, they had to introduce a complete new "private namespace" that is different from the `this.<name>` one, because the latter is already reserved for the visible-to-everyone properties (messing with that would have serious compatibility implications). Hence the `#foo` syntax.
- sjroot 8y agoThat is a very important clarification and I imagine TypeScript will leverage this new feature. That said, I still don't like the #. I think that will be the biggest issue with adoption (at least based on feedback on this post). Would the spec have to come up with another symbol if they wanted to implement `protected` behavior? Alternatively: `this.private.value`, `definitelyNotThis.value`
- jamestimmins 8y agoDoes this mean that with TypeScript someone could still see private values if they used their developer console on the browser, but with this approach that would be impossible?
- james-mcelwain 8y agoAccess modifiers in TS are compile time only checks. This change is not about visibility in dev tools. I'd imagine you'll still be able to see and mutate private fields in dev console, just like you can in a Java debugger, etc. This change is for libraries, so that if someone consumes a TS library, for example, they can't monkey patch or otherwise touch private fields at runtime.