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

101–110 of 112 posts

Re: Public and private class fields

#101

Post by Roboprog »

Roboprog wrote: post #73
vikingcaffiene wrote: post #46

Earlier quoted context omitted.

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

Well, it’s a little shorter if not a lot shorter

Re: Public and private class fields

#102

Post by hombre_fatal »

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…

Let's not stoop to the "learn2code" condescension on a forum where we're talking to fellow developers. The person you replied to had a perfectly reasonable point.

I use strict FP languages every day and could not figure out what your point was, and your condescending intro and outro makes it hard to continue the discussion with you.

Re: Public and private class fields

#103

Post by lioeters »

shiado wrote: post #50

How does this work with JSON.stringify? Could I convert an object to a string and then scan the string to get the value of the private fields? (I am not great at the details of JS correct me here)

Looks like JSON.stringify will not reveal a private field, based on this line from the spec:

"What do you mean by "encapsulation" / "hard private"? It means that private fields are purely internal: no JS code outside of a class can detect or affect the existence, name, or value of any private field of instances of said class.."

https://github.com/tc39/proposal-class-fields/blob/master/PR...

Re: Public and private class fields

#104

Post by IggleSniggle »

catpolice wrote: post #61
werkjohann wrote: post #40

Earlier quoted context omitted.

I'm curious, is JS your primary language? Getters and setters have been around since ~2010 (other languages also make heavy use of them, like Obj-C). I suspect that you only see this as "invisible" because you first learned a language that didn't have getters/setters (and if you started with modern JS, or Obj-C the fact that properties aren't "dumb" would just be a given). Thoughts?

I've been using languages with getters and setters for long enough to be familiar with them. There was a time that I thought they were useful and used them in my own code. But I've been burned enough, and thought enough about language design that I've come to avoid them. I say they're "invisible" because of the property illustrated by these two statements: foo.bar = 0; foo.baz = 0; One of these gets compiled/JIT-ed i…

Thank you for writing this. I was on the fence about the utility of getters/setters in js, and wasn’t convinced by your first paragraphs. By the end (“if a field gets refactored into a getter, it’s suddenly not enumerable”), I was 97% on board.

Re: Public and private class fields

#105

Post by RandomInteger4 »

jarvuschris wrote: post #29
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…

Wouldn't it be simpler to have a Terms of Service that voids the warranty of code being misused by bypassing the given API?

I mean, not every software problem has to be solved with software.

Re: Public and private class fields

#106

Post by vikingcaffiene »

Roboprog wrote: post #73
vikingcaffiene wrote: post #46

Earlier quoted context omitted.

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

> a culture that wants to force Simula 67 / C++ / Java as the last word on how everything MUST be done.

I mean OOP is very popular so maybe that's where you are getting that impression from? That said, you really could make the same argument for functional programming on HN. I see a _lot_ of commentary much like the parent comment that touts functional as the obviously better way to do things. It always kind of rubs me wrong. If you don't like OOP don't use it and vice versa. Personally I prefer functional programming and use it when I can but I don't think twice about switching it up to OOP if that's whats needed. Just think that it's important to bring all tools available to bear (<= spelling??) when you are attacking a problem. This job is hard enough without succumbing to dogmatic turf wars you know?

Re: Public and private class fields

#108

Post by randomsearch »

BillinghamJ wrote: post #86
randomsearch wrote: post #59

To reiterate what others said, choosing an unusual syntax that is non-obvious motivated by a synthetic example to solve a problem already solved by many other languages in better ways almost raises the suspicion that we’re deliberately trying to make JS even worse... to kill it? Or is this just indicative of the process that got us to this mess in the first place? A more reasonable policy for JS would be to (a) conta…

You know a lot of people actually like JS right? The second paragraph you wrote seems to indicate that you believe people only use JS because they're forced to - since browsers don't support anything else. That's not the case. People choose to use JS in all sorts of places where they could make use of many other options. Development of the JS spec is complicated somewhat by the strict rules of web compatibility. But…

You’re right, I have assumed that people only use JS because they have to. Happy to be convinced otherwise - please respond:

Other places - I guess you mean Node, and VS Code and Electron etc? I’ve always assumed that was either because of the available skill set (web devs know JS, so make their tools on JS) or to reuse JS on the web and elsewhere. So not because it’s a good language, but because people know it or solutions exists in it.

Is that what you meant?

To me, Node (for example) makes sense only if your devs don’t know other languages or you want to hire cheaply - I’d always go for a “proper” (better designed, more stable, elegant, robust) language on the backend given the choice.

Re: Public and private class fields

#109

Post by BillinghamJ »

randomsearch wrote: post #108
BillinghamJ wrote: post #86

Earlier quoted context omitted.

You know a lot of people actually like JS right? The second paragraph you wrote seems to indicate that you believe people only use JS because they're forced to - since browsers don't support anything else. That's not the case. People choose to use JS in all sorts of places where they could make use of many other options. Development of the JS spec is complicated somewhat by the strict rules of web compatibility. But…

You’re right, I have assumed that people only use JS because they have to. Happy to be convinced otherwise - please respond: Other places - I guess you mean Node, and VS Code and Electron etc? I’ve always assumed that was either because of the available skill set (web devs know JS, so make their tools on JS) or to reuse JS on the web and elsewhere. So not because it’s a good language, but because people know it or so…

I am not - and have never been - a front-end or browser JS developer. I did not have JS skills to bring over, and yet Node was my preferred language for writing commercial applications for many years. Now more on the Go side, but still making plenty of Node applications.

It works fantastically well in IO-bound applications for such a large number of reasons. It's not far off the most lightweight option for making simple systems, the ecosystem focusses very much on composition of smaller libs than using hefty frameworks, its single threaded nature is actually a _huge_ benefit (though you wouldn't want to use it for CPU-bound work).

There's also the fact that JS these days is essentially a completely different language from the JS which browsers supported 5 years ago. I started using Node before those changes, but it has only become better with them.

I think you'd be surprised how common this exact story is. A lot of Node engineers are gradually moving over to Go, but it's still a great system in its own right.

Also, in reality, if you're a pre-existing browser JS developer, you're actually going to be bringing a load of baggage which will not help you get used to Node. I'd almost say you're better moving to it if you don't already know the lang.

Re: Public and private class fields

#110

Post by BillinghamJ »

fsnarskiy wrote: post #95
BillinghamJ wrote: post #78

Earlier quoted context omitted.

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?

what i was demonstrating by showing that design pattern is that there is already an easier and clean way to do private variables and scopes. BUT if you want to talk about its speed and efficiency here we go: It very intentionally trades memory space for faster variable resolution. plz read this article - https://www.toptal.com/javascript/javascript-prototypes-scop... he has some test code at the end that compares the…

Bear in mind, in the cases you refer to, the inner functions should only be allocated once - when the file is loaded.

The issue is when you use this pattern for initialising what are effectively classes. Then every time you use `new`, the functions have to be wrapped again.

Post reply on HN