Comment by tnzm | Hacker News Reader

Comment by tnzm | Hacker News Reader

Parent Full thread

I know they're not, that's why I'm objecting to them in principle (even though I use them and they're quite handy). JavaScript already has a solution - just put the private fields in the parent closure where they can't be accessed externally. In my example above, x is a private field, and the constructor function Foo can be asynchronous. The new semantics is a kludge around the supposedly "optional" class syntax sugar.

Remember, once upon a time JS was supposed to be Scheme...

> just put the private fields in the parent closure where they can't be accessed externally

Your approach can't translate the following code:

    class MyNumber {
        #value;
        constructor(value) { this.#value = value; }
        add(other) { return new MyNumber(this.#value + other.#value); }
    }

The proper solution is to use a non-enumerable property with an unnamed Symbol name, which is possible but cumbersome.

You're not supposed to be able to refer to other.#value, though, isn't that the entire point of a private field?

They are private to classes, not instances. Many languages with private fields do allow access to private fields in other instances of the same class.

Reply on news.ycombinator.com