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

71–80 of 112 posts

Re: Public and private class fields

#71

Post by danShumway »

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

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.

Re: Public and private class fields

#72

Post by catpolice »

fsnarskiy wrote: post #68
azov wrote: post #42

Earlier quoted context omitted.

Getters/setters are useful. E.g. maybe you had a class 'Box' with a field 'area'. Later you added fields 'width' and 'height'. What are you going to do? Change 'area' to 'getArea()' and break the API? Write extra code to ensure that you update area every time you change width or height? Or write a getter that returns width*height? I'd say getter is the cleanest option in many cases.

Please for the love of god learn functional programming. this is a primary example of being stuck thinking there is a RIGHT way to do things according to Object oriented design practices. Firstly objects in JavaScript are not classes, they are just your good old dictionary value store, to an JavaScript object it doesn't matter if u put a function or a value under its property, under the hood its just a pointer pointi…

Who are you talking to here?

Re: Public and private class fields

#73

Post by Roboprog »

vikingcaffiene wrote: post #46
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.

If you are trying to evangelize for functional programming this is the wrong way to do it. “OO people” is not a thing. I can code in both functional and OO style and choose the one that best suits the scenario. Segregating into an us vs them or right vs wrong comes off as a bit smug and holier than thou. I’m sure that wasn’t your intent but just sayin.

On the one hand, I hear what you are saying, but on the other hand, I share the original poster’s frustration with what seems to be a culture that wants to force Simula 67 / C++ / Java as the last word on how everything MUST be done.

He’s venting, not evangelizing.

And his solution is a lot shorter and easier to follow than the drawn out OOP style version, even if I would have put the 2 functions in the returned object literal on their own lines.

Re: Public and private class fields

#74

Post by BillinghamJ »

danShumway wrote: post #67

Am I the only person who's really stinking annoyed that Chromium is just randomly shipping features that haven't gone through the W3C? Didn't we learn anything from the early days of CSS and browser flags? Didn't we learn anything from flexbox? Don't call it a proposal if you already have plans to ship it. Private fields haven't been accepted as a standard yet. They should not be shipped except behind a browser flag.

First, the definition of JS has nothing to do with W3C. (Also for HTML, nobody really cares what W3C thinks anyway)

Second, the rules of how JS is standardised is that changes are actually not allowed to go into the final spec until at least two major players implement support. So this is _exactly_ how it's meant to be done.

A substantial amount of discussion and consideration has already happened prior to this point, as well as implementations into transpilers (eg Babel) which people have been using for some time.

This comment explains a bit further: https://news.ycombinator.com/item?id=18676717

Re: Public and private class fields

#75

Post by danShumway »

Roboprog wrote: post #70
danShumway wrote: post #67

Am I the only person who's really stinking annoyed that Chromium is just randomly shipping features that haven't gone through the W3C? Didn't we learn anything from the early days of CSS and browser flags? Didn't we learn anything from flexbox? Don't call it a proposal if you already have plans to ship it. Private fields haven't been accepted as a standard yet. They should not be shipped except behind a browser flag.

https://en.m.wikipedia.org/wiki/WHATWG Good or bad, that is the governing body the browser makers honor.

Fair point; I get mixed up, since both organizations are pretty active and proposals are often submitted to both. Regardless, even in this case this proposal is being submitted to TC39[0]. It's in stage 3 of 4[1].

Stage 3 proposals should not be shipped on by default. There still may be spec changes between a stage 3 and stage 4 proposal.

[0]: https://github.com/tc39/proposal-class-fields

[1]: https://tc39.github.io/process-document/

Re: Public and private class fields

#76

Post by jamestimmins »

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…

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?

Re: Public and private class fields

#77

Post by Roboprog »

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?

Yes, especially if the result is only used in a small number of nearby places, which is usually the case.

My IDE can easily infer the properties of such objects, as well as display the JSDoc for such properties.

Re: Public and private class fields

#78

Post by BillinghamJ »

fsnarskiy wrote: post #63

Why? I feel like the person who proposed this is relatively young and newer to coding. The reason why i say this is the functionality he is proposing can already be done using one of the myriad of JavaScript design patterns - https://addyosmani.com/resources/essentialjsdesignpatterns/b... It can already be done in a clean and easy way with a an anonymous self executing function - (function(){//EVERYTHING HERE IS PRIV…

Making classes (or equivalent) in the way you propose - ie "make use of closures for private instance fields" - does not work well. It requires allocating a new copy of each of the class's methods every time the class is instantisted, working around the prototype system.

If we're arguing about crappy misuse/abuse of JS and "doing it wrong", surely this is far worse?

Re: Public and private class fields

#79

Post by BillinghamJ »

vikingcaffiene wrote: post #44

Not gonna mince words. The hashtag syntax is hot garbage. If you need this kind of functionality just use a super set language like TypeScript. It looks and behaves exactly like you would expect.

Although TypeScript is intended to be a superset of JS, it isn't always. There have been occasions where JS features were not usable via TS due to existing incompatibles/differences in implementation of new JS syntax. Really it is a different language.

Re: Public and private class fields

#80

Post by Roboprog »

lioeters wrote: post #36
21 wrote: post #17

Earlier quoted context omitted.

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

I often use a functional style as the OP's above, instead of classes, but I wonder about performance hit. Calling it often (like many "instances") and creating new functions every time seem less efficient that inheriting methods via prototype.

If I were to create 300 instances of something with actual func^H^H^H^H methods attached, rather than 3 instances, I would probably look into creating a prototype and coping with the perils of “this” usage, but otherwise, I’m not going to lose much sleep about it.
Post reply on HN