5 ms·

This syntax is...odd. It is not expressive and comes off as a "language hack." The only people who would understand it are those who happen to stumble on this a

by sjroot 8y ago

This syntax is...odd. It is not expressive and comes off as a "language hack." The only people who would understand it are those who happen to stumble on this article. Frankly, if this is an issue that you are concerned about, you should really invest the time to learn (and possibly migrate to) TypeScript. Specifically, see their class documentation which already has support for `public`, `private`, and `protected` [1]. (Edit: read @denisw's reply regarding TS. I make this suggestion specifically for TS's compile-time assistance regarding private field access.) It actually kind of boggles my mind that V8 engineers sat down and agreed that this would be a good design decision. Granted, the article says that they are proposals—is there any way to provide feedback on this? (Edit: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-arent-declarations-private-x https://github.com/tc39/proposal-class-fields/blob/master/PR...) [1] https://www.typescriptlang.org/docs/handbook/classes.html https://www.typescriptlang.org/docs/handbook/classes.html

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 ago
  That 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 ago
  Does 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 ago
    Access 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.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
_zachs 8y ago
Agreed completely! This article was the final push for me to start learning TS. I'm really surprised something like this came out of Google.
danShumway 8y ago
Agreed. This proposal seems very sloppy, and I'm disappointed to see that it managed to get to Stage 3. There is good reason to talk about adding some kind of private or controlled access in Javascript beyond closures. I've often wanted exactly that kind of feature. However, it shouldn't be done through the lens of classes. Classes are largely just syntactic sugar over Javascript's real inheritance model, the prototype chain. Whatever solution is come up with should be something that can described in terms of the prototype chain (or ideally, described in terms of pure objects). That's not to say it shouldn't work with classes, obviously it should. But it should be designed from the bottom up, not the top down. The fact that this proposal is only applied to classes, and the fact that it does not mention the underlying mechanics about how this would work in the core language underneath classes makes it feel poorly designed. Classes in Javascript aren't magic, we can't just apply an entirely new concept on top of them with no explanation of how it fits into the broader language.

by sjroot 8y ago

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 ago
That 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 ago
Does 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 ago
  Access 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.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

_zachs 8y ago

Agreed completely! This article was the final push for me to start learning TS. I'm really surprised something like this came out of Google.

danShumway 8y ago

Agreed. This proposal seems very sloppy, and I'm disappointed to see that it managed to get to Stage 3. There is good reason to talk about adding some kind of private or controlled access in Javascript beyond closures. I've often wanted exactly that kind of feature. However, it shouldn't be done through the lens of classes. Classes are largely just syntactic sugar over Javascript's real inheritance model, the prototype chain. Whatever solution is come up with should be something that can described in terms of the prototype chain (or ideally, described in terms of pure objects). That's not to say it shouldn't work with classes, obviously it should. But it should be designed from the bottom up, not the top down. The fact that this proposal is only applied to classes, and the fact that it does not mention the underlying mechanics about how this would work in the core language underneath classes makes it feel poorly designed. Classes in Javascript aren't magic, we can't just apply an entirely new concept on top of them with no explanation of how it fits into the broader language.