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

31–40 of 112 posts

Re: Public and private class fields

#31

Post by dmitriid »

ihuman wrote: post #14
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.

What are some other examples of the class keyword ruining Javascript?

It’s a non-fitting abstraction that’s poorly glued on top of a prototype-based language.

As a result, uou have thongs like:

- methods have no access to `this` on the instance of the class. Because they are defined on the prototype. As a result, you have to manually do a .bind(this) in your constructor for every method that needs access to `this`

- meanwhile, if you define a class field: `field = () => this.foo` (with an arrow function), then you have no problems accessing the instance. Because of different scoping rules, binding etc.

- and now there’s private fields. Which are just a hack to make them sorta kinda work

Re: Public and private class fields

#32

Post by mothsonasloth »

Since ES6 it seems like the language is having an identity crisis. Trying to cherry pick OO concepts here and there.

If Javascript is determined to become fully object oriented, then it might as well just adopt the tried and true concepts in C++/Java for encapsulation.

This just seems like a painful and less verbose way of forcing encapsulation.

I can appreciate Ruby and Python users might not be happy with this convention but this is going to end up in tears I think, maybe not PHP level but still...a mess!

Re: Public and private class fields

#34

Post by sbr464 »

dberg wrote: post #11

Maybe I’m old school but instead of private it looks like they accidentally commented out a variable. # does not feel idiomatic to me.

I agree, also, it definitely doesn’t help readability. That being said, the underlying private feature is appreciated.

Re: Public and private class fields

#35

Post by oaiey »

I always understood that some of the JS language quirks are due to their humble beginnings. Nowadays however I expect professional decision making.

In 2018 I expect that a language which in many other regards follows the C++ language syntax style (semi colon, curly braces, double equality, ...) follow also expectations like that private fields are declared with a private keyword and not some strange new syntax form.

Disappointed!

Re: Public and private class fields

#36

Post by lioeters »

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?

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.

Re: Public and private class fields

#37

Post by Twirrim »

Maybe I'm misunderstanding something here.

This reads like Google is now attempting to dictate the direction Javascript goes in, by implementing proposals before they've become standards, and shipping them in their browser. Given the dominance of the browser engine, it effectively sets the direction of the language, particularly if people start to use it (which they will).

This is feeling like IE6 all over again. We're getting non-standard implementations of standards, that will further encourage websites to be "Chrome only".

Re: Public and private class fields

#38

Post by mkozlows »

Twirrim wrote: post #37

Maybe I'm misunderstanding something here. This reads like Google is now attempting to dictate the direction Javascript goes in, by implementing proposals before they've become standards, and shipping them in their browser. Given the dominance of the browser engine, it effectively sets the direction of the language, particularly if people start to use it (which they will). This is feeling like IE6 all over again. We'…

Implementing proposals before they become standards is totally normal and a good way to prove out the proposal. Google's implemented tons of proposals, and generally pulled out the ones that didn't become standardized.

Re: Public and private class fields

#40

Post by werkjohann »

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