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

41–50 of 112 posts

Re: Public and private class fields

#41

Post by [deleted] »

werkjohann wrote: post #40
catpolice wrote: post #22

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: unles…

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?

[deleted]

Re: Public and private class fields

#42

Post by azov »

catpolice wrote: post #22

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: unles…

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.

Re: Public and private class fields

#43

Post by te_chris »

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.

I went to a lunch with Douglas Crockford in London and was lucky enough to be seated next to him. Got to ask lots of questions about what he thought of new JS and he was unequivocal: All the new class shit is a hack by people determined to turn JS into C#. I agree with him. I don't get why people are wasting their time on private class members when features like pattern matching and the pipeline operator are making their way to the surface. Classes are the worst thing to happen to JS.

Re: Public and private class fields

#45

Post by becausereasons »

I've seen very few people outside of TC39 express a need for "truly private" fields in JS, and I've seen ever fewer offer positive comments about the syntax. On the other hand, I've seen a good amount of bellyaching about it. I think cramming a fairly unpopular proposal (the #) into a genuinely popular one (class fields) and calling it a day is going to make some folks pretty unhappy.

...at any rate, I was unimpressed with the sigil when I first saw it, and that hasn't changed. I've resigned myself to throwing it in the bin of JS features that I won't be using, like `with`, `eval` and `==`.

Re: Public and private class fields

#46

Post by vikingcaffiene »

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.

Re: Public and private class fields

#48

Post by pacala »

azov wrote: post #42
catpolice wrote: post #22

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: unles…

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.

Thanks for providing a great example of useful getters. If you're computing a derived property that depends strictly on the data at hand and its attributes, getters are useful. When designing code, follow the Getter Idempotency Principle:

* Given a reference to a data entity, invoking a getter on the data should always return the same result, no matter how many times it is invoked, no matter how the rest of the program or world state evolve.

There are others situations. In those situations explicit code is preferable:

* Change an attribute of a data. Do not use a setter, period. Create a data copy with the attribute changed instead. Even GUI toolkits nowadays are using immutable data patterns with great success, see React.

* Use a data entity as a facade for reading data from a 3rd party API. Instead of using an object that pretends to be data but isn't via a heavy getter, use the 3rd party API explicitly to instantiate your immutable data graph.

* Use a data entity as a facade for updating a 3rd party API. Don't use a setter, instead create an updated copy of your data, then explicitly invoke the 3rd party API with the updated data copy.

Re: Public and private class fields

#49

Post by mkozlows »

azov wrote: post #42
catpolice wrote: post #22

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: unles…

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.

"Breaking the API" is what we call "refactoring" in the (extremely common) case where your code is only used in a single project, and not part of a reusable library.

And yeah, if you radically rework how you make your boxes work, that's a good time to do a refactor. But there's no reason to anticipatorily add in a bunch of complexity so that you don't have to convert a value to a property at some hypothetical future point.

(I mean, among other things, if you put your area property behind get/set methods, you still have to go and change all the setters anyway, since in your brave new width 'n' height world, setting area is nonsensical. So your API still breaks, and you still need to change your consuming code. What was the benefit of the getters/setters then?)

Re: Public and private class fields

#50

Post by shiado »

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)
Post reply on HN