Using # as part of the name of the field is not javascripty

[fresheneesz]

I can understand that private varaibleName breaks backwards compatibility because private hasn't been a keyword (for some reason) and so people might be using it as a variable name. I can understand using syntax like let #a = 'whatever' in that context, even tho it's super ugly.

But it absolutely makes no sense to make the # mark a part of the identifier itself. Nowhere else in javascript do we do this. This isn't perl folks. The identifier should be just a name. We can all agree the following would look absurd:

class A {
  const x = 5
  setX(value) {
    this.(const x) = value
  }
}

But that's basically what you're doing with the hash mark. Just replace const with #:

class A {
  #x = 5
  setX(value) {
    this.#x = value
  }
}

In my opinion the above is just as absurd as the first example. Why make the # part of the identifier? Why not do the following?

class A {
  #x = 5
  setX(value) {
    this.x = value // No hash mark needed (or wanted)
  }
}

Or better yet, why even use the hashmark when you can do the thing everyone is already familiar with:

class A {
  private x = 5
  setX(value) {
    this.x = value // No hash mark needed (or wanted)
  }
}

The above should not break backwards compatibility because the 'private' is in the top-level of the class, which must have one of the following forms:

• private name ...
• private declarator name ...
• declarator private name ...
• name(...) ...

So even tho private can be used as a name, it should be entirely unambiguous in this context. So why aren't we doing this?

But number 1, please do not make the # mark part of the identifier. I don't want to have to be doing myInstance.#thing all over the place. Its absolutely fugly and surprising in all the worst ways.

[ljharb]

this.x would conflict between the public field of the same name, that external code might install.

Additionally, i wouldn’t find it an improvement to be unable to simultaneously use (without bracket notation) a public and private field both named, say, “id”.

[littledan]

We've had extensive discussions about this question; this issue is a duplicate of several others, such as #10. Please refer to https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md for background.

[fresheneesz]

@ljharb

this.x would conflict between the public field of the same name, that external code might install.

External code should never be "installing" (ie monkey patching) things on another class. If they do, that's on them for bad design.

i wouldn’t find it an improvement to be unable to simultaneously use (without bracket notation) a public and private field both named, say, “id”.

99.9999999% of the use cases of classes do not need to be used as hashmaps, where you would need such behavior. Its perfectly reasonable to keep public and private members and methods in the same namespace. Pretty much every single other widely used language does it that way. What reason do you think its not an improvement?

[jridgewell]

Its perfectly reasonable to keep public and private members and methods in the same namespace.

We already have this, they're underscore properties.

class Foo {
  _bar = 1;
}

Pretty much every single other widely used language does it that way. What reason do you think its not an improvement?

Every other language has a static type checker to achieve this, or they've doing access-time checking. Neither of those is acceptable in JS (we're dynamic, and access-time checking would cause a significant slowdown in all of the language, not just private fields).

[fresheneesz]

underscore properties.

Those aren't private.

static type checker .. or .. access-time checking

Javascript interpreters are modern marvels that have other options than static type checking or access-time checking. As I'm sure you're aware, V8 uses hidden classes to optimize what would otherwise be slow access-time checks. Why can't the same optimizations be done for private properties?