Treating the `#` as part of a `.#` operator instead of as part of a field name `#foo`.

[trusktr]

The following should work, and it would mean that we can provide much better functionality:

class Foo {
  #      x = 5

  test() {
    console.log(this  .#      x) // it should work, but it doesn't
  }
}

It didn't work in Chrome (I am doubting it is a bug in Chrome, and that is it working as spec'd, which throws a syntax error).

Looks like the #foo is treated as a name, which is what makes things like indexed-access not currently possible (or so it seems).

If we change the semantics so that .# is an operator (f.e. it means "access a private property, of which the name follows"), and can be separated by spaces just like with public access using ., then we can accommodate other features like indexed access in a way that makes sense:

const propName = 'bar'

class Foo {
  foo = 3
  # foo = 4
  [# propName ] = 5

  test() {
    console.log(this  .      foo) // it works, 3
    console.log(this  .#      foo) // it should work, 4
    console.log(this[#'foo']) // it should work, 4
    console.log(this   [#   'foo' ]) // it should work, 4
    console.log(this  .#      bar) // it should work, 5
    console.log(this [#    propName ]) // it should work, 5
  }
}

because now the syntax is tied to the type of access you want to attempt, not tied to the name of the field.

[trusktr]

Then we can have dynamism and be closer to JavaScript origins:

const privateProps = ['foo', 'bar', 'baz']

class Foo {
  constructor() {
    let i = 0
    for (const privProp of privateProps) {
      this[#privProp] = i
      // or with any spacing this[ # privProp  ] = i
      i++
    }
  }
}

With creativity, you can imagine use cases for this, like mapping a definition from an external helper (such as a decorator, mixin, or class factory) to private properties.

[ljharb]

I disagree that it should work. # is part of the name, and this is an important part of the mental model.

Separately, i don’t agree dynamism makes sense for this feature, given that you can store any kind of object or collection you want in a private field if you need to iterate.

[trusktr]

I suppose by "mental model" you are referring to the very proposal of this github repo, which many people don't like.

You know, you (tc39 in general) can change the proposal (and the mental model) to something that people like more.

[trusktr]

Honestly speaking, in this.#foo, the name does not intuitively seem to be #foo.

Valid JavaScript identifiers have never had # symbols. I wouldn't suddenly think #foo to be valid. Try it yourself here: https://mothereff.in/js-variables

This makes no sense with respect to this['#foo'], obviously.

The mental model is gross.

[ljharb]

“what people like” is important but certainly not the reigning concern. There is nothing people like more that meets all the constraints of the committee, which is why this proposal as-is is what’s shipping in browsers.

[nicolo-ribaudo]

Note that, in case TC39 change their mind and decides that dynamic access is a necessary feature, the syntax of this proposal doesn't prevent a possible future this[# "foo"] syntax.

[trusktr]

That seems to be wrong. According to @DanielRosenwasser in #248 (comment),

My feeling from speaking with a decent number of members of the committee is that many people are saying "Set was actually the right one, but I think it's probably too late."

So, there are things people like more. Some constraints should be modified.

Note that, in case TC39 change their mind and decides that dynamic access is a necessary feature, the syntax of this proposal doesn't prevent a possible future this[# "foo"] syntax.

Then, in that case it is important to shift the mental model so that .# is an operator, and foo is a name. And thus we may as well allow spacing.

It's not a huge change. I don't think it affect the currently functionality.

[trusktr]

If we could roll back a much more useful feature such as Object.observe, we can certainly roll back private fields (and change public and static ones to [[Set]]).

[ljharb]

That was stage 2. This is stage 3. It’s not being rolled back.

[trusktr]

Remember, private fields was unfairly rushed from stage 2 to stage 3 in just two months. It shows a lack of respect towards end users (with regards to this feature) on behalf of TC39.

[ljharb]

There’s nothing “unfair” about that; there is no proscribed minimum or maximum for a proposal to be at any stage.

[trusktr]

Of course, a person burglarizing a home doesn't think what they do is unfair. I'm the end user (the person whose home is burglarized).

[jhpratt]

@ljharb Perhaps there should be. A number of people feel this was rushed.

[jridgewell]

Petty arguments (both sides) aren't really productive.

The committee has been discussing private fields for 6 years. This is the first design that has managed to gain real traction. Going back to stage 2 isn't going to produce a better design, it's just going to stagnate it more.