Public and private class fields

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 into a few assembly instructions and the other calls an O(n^2) function (with side effects) on a giant tree structure that foo is a part of. You can't guess which is which from looking at those, unless you've read the source for the foo class and memorized which properties are behind setters. They're "invisible" because you can't see when you're using one.

A good property for code to have is that you can infer its semantics from its syntax with as little outside information as possible. When you read a line of code, you should get reliable clues about what that makes the computer do. You might not need to know /all/ the details - e.g. a method call encapsulates the details of an operation but the name (and documentation) give you a good idea of what's happening.

The problem with getters and setters is that they do more than abstract away details, they cloak potentially important semantic information about code in ways that can be misleading.

By contrast, if I read:

foo.setBar(0); foo.baz = 0;

I might not know all the details about what setBar does, but at least I have a clue that it's more complicated than the following line.

I've been burned IRL by this kind of thing - I've seen very expensive getters mysteriously ruin hot loops (making what looked like a linear operation into an O(n^3) operation) and developers pulling their hair out because of setters that silently rejected values and all sorts associated headaches. Working in settings where they came up semi-frequently made me feel like complexity could be hidden anywhere, and reduced my confidence that I understood code that I read.

JS and other languages with reflection have a whole host of associated issues. If a field gets refactored into a getter, it's suddenly not enumerable and will silently fall out of a lot of copy operations. Suppose you want to find every place that the setter gets called, so you grep for `.bar = ` but did you remember the myriad of other ways that setter could get called (e.g. foo["bar"] =, foo[someVariable] =, Object.assign, etc.)?

In my experience, unless you have some extremely strong reason why you can't refactor or some very well-defined standards about when to use them, they're not worth the trouble they bring when code suddenly stops behaving the way you expect it to.

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 PRIVATE SCOPE})();

this also has massive added benefits to execution time and variable name resolutions.

Learn more about variable scopes and how powerful JavaScript is.

Also recognize that JavaScript is much closer to a functional programming language than a typical Object oriented language. If u are going to try and make JavaScript objects try and behave like classes that you know and love from java, you are gonna have a BAD time. its going to take way longer to code, gonna be hard to maintain and reason about it. Try instead to write asynchronous event driven code where functions pass data around rather then data passing functions around.

Also it is really dumb trying to set private/public fields in JavaScript code that runs in the browser, i can still easily access all the variables through a debugger or running in a custom environment( like Selenium).

and if your concern is about keeping that data safe in a server environment.. well then your really shouldn't rely on private/public to keep you safe and put in actual user role management and access at the application level, and one of the best way to do that is utilize a graph database to store and resolve complex user roles and permissions in your application.

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

You seem to be proposing a Catch-22 that would freeze JavaScript forever: no one should implement a feature before it is a standard, but completing the process to become a standard requires implementations to exist. Therefore, no new feature can ever be implemented or become part of the standard.

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.

Agreed completely! This article was the final push for me to start learning TS.

I'm really surprised something like this came out of Google.