Clarify behaviour of private fields

[dmitriid]

Based on https://medium.com/the-thinkmill/javascripts-new-private-class-fields-93106e37647a

class Point {
  #x;
  #y;
  
  constructor(x, y) {
    this.#x = x;
    this.#y = y;
  }
  equals(other) {
    return this.#x === other.#x && this.#y === other.#y;
  }
}

The code for equals breaks assumptions about private fields. A private field is expected to be instance-private and non-accessible anywhere.

It looks like if a method happens to be in class A and and arbitrary variable happens to be of type A, then the method can access the variable's private fields at a whim.

[littledan]

This proposal was designed with class-private, rather than instance-private, semantics as a goal. Many other programming languages operate this way. What drives the expectation that it be instance-private for you?

[dmitriid]

It was my feeling that most popular languages have instance-private fields. Now I realise it's more of a 50-50-ish split :)

[bakkot]

Out of curiosity, what languages have instance-private fields? Off the top of my head I can't think of one - C++, Java, Python, PHP, Swift, TypeScript, etc all have some notion of a class with a private field, and in all of them it's class-private or something even less restrictive.

[littledan]

Maybe Ruby?

[ljharb]

(fwiw, in Ruby, nothing is hard-private due to .send)

[dmitriid]

Argh. Look slike I've spent too much time in languages which have modules instead of classes and I forgot all about privates :)

[littledan]

OK, let's stick with class-private then.