3 ms·
> that new "#private" thing I can agree that classes have been more or less a syntactic sugar, but private identifiers are not. The field name collision is a p
by lifthrasiir 5y ago
> that new "#private" thing
I can agree that classes have been more or less a syntactic sugar, but private identifiers are not. The field name collision is a problem in virtually every dynamically typed language with namespace inheritance and each language has their solutions (see Python `__mangled_name` and Ruby `@instance_var`), JavaScript just happens to have another solution and that alone justifies a separate `class` syntax (since the scope of such private identifiers should be lexical).
- tnzm 5y agoI 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.