3 ms·
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
by tnzm 5y ago
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...
- lifthrasiir 5y ago> 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.
- tnzm 5y agoYou're not supposed to be able to refer to other.#value, though, isn't that the entire point of a private field?
- lifthrasiir 5y agoThey are private to classes, not instances. Many languages with private fields do allow access to private fields in other instances of the same class.