Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public and private class fields

developers.google.com

Post reply on HN
Print view View original

21–30 of 112 posts

Re: Public and private class fields

#21

Post by denisw »

sjroot wrote: post #3

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` […

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.` 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.

Re: Public and private class fields

#22

Post by catpolice »

First, like the other commenters, I'm not in love with the perlish # syntax. I'm not sure why it was wise/necessary to add a previously illegal character as a prefix, rather than adding a "private" keyword, but I'm sure there's some reason.

Second, the example affords an opportunity to rant about a pet peeve of mine.

"Now ask yourself, how would you implement this class in JavaScript?"

I wouldn't. Listen folks: unless you're doing some weird/temporary debugging or you need to add some meta-functionality (e.g. logging) to an API that reeallly can't change, don't write getters/setters. If accessing or setting a property needs to do computation or have side effects, refactor so that it's done explicitly by calling a method. Anything that lets you attach invisible effects to normal syntax is an anti-pattern because it makes your code behave differently than it appears to, and therefore it's harder to reason about from the outside.

Re: Public and private class fields

#23

Post by toastercat »

21 wrote: post #17
mkozlows wrote: post #5

This is Exhibit N for the "the class keyword is ruining Javascript" prosecution. If you want a "private variable" you just use a closure. let incrementer = () => { let x = 0; return { value: () => x, increment: () => x++ }; }; It's like the OO people are determined to forget about the functional concepts that made JS great.

and now you are defining you whole class inside that return {}. Do you honestly find this more readable?

This is similar to the Revealing Module Pattern in Learning JavaScript Design Patterns: https://addyosmani.com/resources/essentialjsdesignpatterns/b...

I think it's perfectly readable, and it requires no more language hacks that obfuscate the JavaScript underlying `class` syntax sugar.

Re: Public and private class fields

#24

Post by mpweiher »

mkozlows wrote: post #5

This is Exhibit N for the "the class keyword is ruining Javascript" prosecution. If you want a "private variable" you just use a closure. let incrementer = () => { let x = 0; return { value: () => x, increment: () => x++ }; }; It's like the OO people are determined to forget about the functional concepts that made JS great.

The JSR instruction is ruining assembly! I mean, you can just push the PC, then JMP to the address. And all that the pesky RTS instruction is doing is popping an address from the stack into the PC. Who needs it?!?

Re: Public and private class fields

#25

Post by sjroot »

denisw wrote: post #21
sjroot wrote: post #3

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` […

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 nee…

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`

Re: Public and private class fields

#28

Post by [deleted] »

sjroot wrote: post #3

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` […

[deleted]

Re: Public and private class fields

#29

Post by jarvuschris »

RandomInteger4 wrote: post #27

What problem do private fields solve?

When you're building a component that will be used as part of larger applications, possibly written by other people, declaring things as private lets you cordon off internal parts of the component so that it's safer to change them in the future without breaking the applications using it

Someone trying to make an application work that is looking at your classes in a debugger is going to poke at whatever inside details they can see that helps them get their job done quicker. Now if you change that their application breaks when they update. Not good for anyone.

Privates make it easier for component developers to get things done without worrying about breaking users, and makes it easier for users to upgrade their components without it breaking as much

Re: Public and private class fields

#30

Post by eadmund »

21 wrote: post #17
mkozlows wrote: post #5

This is Exhibit N for the "the class keyword is ruining Javascript" prosecution. If you want a "private variable" you just use a closure. let incrementer = () => { let x = 0; return { value: () => x, increment: () => x++ }; }; It's like the OO people are determined to forget about the functional concepts that made JS great.

and now you are defining you whole class inside that return {}. Do you honestly find this more readable?

This is why macros and a homoiconic language are such a good thing: you can add syntax sugar to have something which is both straightforwardly implemented and readable.
Post reply on HN