Use this#prop instead this.#prop

[uMaxmaxmaximus]

dot will mean access to public fields and sharp will mean access to private fields. This syntax is nicer and more logical than combination of points and sharp

class EventEmitter {

  constructor(){
    this#handlers = []
  }

  on(handler){
    this#handlers.push(handler)
  }

  emit(){
    for(let handler of this#handlers) handler()
    this#clearAll()
  }

  #clearAll(){
    this#handlers = []
  }

}

Thus, the human brain will understand if we look through the point, we then turn to the public fields, if the appeal through the sharp, then to private. Also, there is no excess syntax.

Sharp does not seem much to stand out, but it's only because he did not syntactically highlighted the current engine. Here I have drawn for you an example, as if it might look like in code editors in the future:

P.S. Squares, is my font so look empty arrays []

[littledan]

I think the main problem with this proposal is that it's an ASI hazard. If we allow #foo as shorthand for this#foo, then what do we make of code like this?

Class A {
  #bar
  b() {
    foo()
    #bar.baz()
  }
}

Does that code call .baz() with the receiver of foo()#bar or this#bar?

[uMaxmaxmaximus]

@littledan > foo()#bar

Private properties can only be inside this, no? Private class fields.
And then refer to them only through this, no?

code will be:

Class A {
  #bar
  b() {
    foo()
    this#bar.baz()
  }
}

Word is this association in people that we turn to the current context, it is not necessary to remove and replace at Sharp. This will cause the brain confused.

The algorithm is:

1. The brain see this keyword
2. Brain understand that we now address to the context
3. If after this located dot, the brain realizes that we access to public property.
4. If after this located sharp, the brain realizes that we access to private property.

[littledan]

The proposal in this repository is class-local, not instance-local. For example, if you want to make an .equals() method, you should be able to see the private fields of the argument. @wycats has argued that the shorthand notation of #bar is important to make private state more ergonomic than public state rather than the same or less, in order to encourage its use.

[uMaxmaxmaximus]

You mean to make sugar for this:

class Cat {

  constructor(){
    this.arr = []
    this.arr.#prop = true
  }

  setArr(arr){
    if(arr.#prop) return;
    this.arr = arr
    this.arr.#prop = true
  }

}

compile to:

let prop = Symbol()

class Cat {

  constructor(){
    this.arr = []
    this.arr[prop] = true
  }

  setArr(arr){
    if(arr[prop]) return;
    this.arr = arr
    this.arr[prop] = true
  }

}

That is, the symbols are automatically created, which we can use as we want? Not only in this ???

ITS EPIC IDEA, OMG =)!!! I truly understand your ideas?

That is, symbols are seen in the scope of the class, and other symbols are visible in the file scope?

like #prop and ##prop , no?

[littledan]

Well, the proposal in this repository is based on WeakMaps, not Symbols, but yes, there is support for accessing things other than this.