[Suggestion] Consider to use time proof solution with private and protected keywords

[redradist]

Hi,

From my point of view it seems like mistake to use # for private fields, because it is not extensible ...
If in future we would want to use protected field, it will make harder to implement it ... -# ??!

I think we should not reinvent the wheel and just to use time proof solution with private and protected keywords ;)

[bakkot]

Please see the FAQ.

[rdking]

@bakkot I know it's been discussed to death, that's why I'm not going to argue with you. However, if at all possible, I would like an explanation. From the FAQ:

---

Why aren't declarations private x?

This sort of declaration is what other languages use (notably Java), and implies that access would be done with this.x.

---

The part in bold is where I've always had issue. ES is a language where both a.b and a["b"] have always meant "public access". Why would the introduction of private x in such a language suddenly cause a.x to refer to private access? To my understanding, such an implication would only be possible if the presence of private x also restricted the possibility of a "public" x declaration. Since that is not the case (due to the desire for full encapsulation), on what grounds is it reasonable to claim the implication in the FAQ? I already understand the argument that this is how it is in other languages supporting the use of private x, however I believe that argument invalid as in those languages, the aforementioned restriction exists as well.

---

As I stated before, I will not argue. I'm only looking for the justification for this supposed implication.

[ljharb]

I think your questions are about “why would seeing this.x make someone think it’s private” - which i agree, It wouldn’t! To me, it’s that seeing “private x” would suggest to someone that they could access the private data with “this.x”, which of course they couldn’t, which would be very confusing.

[rdking]

@ljharb

think your questions are about “why would seeing this.x make someone think it’s private”

Um, no. My question is exactly as I stated it. It's about why "private x implies this.x", especially given that both a private member and a public member can be defined for the same instance object. Since it's already set in stone that this.x is public, and that will never change without breaking the language, why would any new notation suddenly suggest that this.x can be non-public?

[ljharb]

@rdking because i don't think people think about public/private in that way. I think if they see private x inside a class, they'll assume that this.x = privateData is setting the data privately. The risk of doing this is that private information could be easily made public, which can have disastrous encapsulation consequences.

[redradist]

@bakkot I know it's been discussed to death, that's why I'm not going to argue with you. However, if at all possible, I would like an explanation. From the FAQ:

Why aren't declarations private x?

This sort of declaration is what other languages use (notably Java), and implies that access would be done with this.x.

The part in bold is where I've always had issue. ES is a language where both a.b and a["b"] have always meant "public access". Why would the introduction of private x in such a language suddenly cause a.x to refer to private access? To my understanding, such an implication would only be possible if the presence of private x also restricted the possibility of a "public" x declaration. Since that is not the case (due to the desire for full encapsulation), on what grounds is it reasonable to claim the implication in the FAQ? I already understand the argument that this is how it is in other languages supporting the use of private x, however I believe that argument invalid as in those languages, the aforementioned restriction exists as well.

As I stated before, I will not argue. I'm only looking for the justification for this supposed implication.

@rdking Disagree with you, because if you say why private x should cause a.x to refer to private access, then why a.x can always cause to return undefined, but setter still will work:

let obj = {
  get x() {
    return undefined;
  },

  set x(value) {
    ...
  }
};

And from user point of view it can seem like x has special behavior and it is !!

Also adding to name # break SOLID, Single responsibility
Name in such case serve two separate goal - access modifier and name of property ...
It is not extensible enough, because what if in future you will add another modifier, how it will look ... ???
Like this -#x or like this %#x ...

There is reason why other languages use private, protected ... because it shows intent directly that this field is private ...

Anyway we can argue about it, but actually I use such convention in Python like _ and __, but it has drawbacks that it is not obvious that this name has special meaning ...

[redradist]

@ljharb

think your questions are about “why would seeing this.x make someone think it’s private”

Um, no. My question is exactly as I stated it. It's about why "private x implies this.x", especially given that both a private member and a public member can be defined for the same instance object. Since it's already set in stone that this.x is public, and that will never change without breaking the language, why would any new notation suddenly suggest that this.x can be non-public?

@rdking Acctually I do not understand why a.x access is backed into language that it always should be accessed ?

[rdking]

@ljharb

i don't think people think about public/private in that way.

So to be clear, it's just an assumption?

[rdking]

@redradist

Disagree with you, because if you say why private x should cause a.x to refer to private access, then why a.x can always cause to return undefined, but setter still will work:

2 things:

1. I never said that private x should cause a.x to refer to private access. I did, however, state that this is an implicit assumption in the presumed implication. I think it's rather off-putting of TC39 to have such an assumption buried in their justifications.
2. I don't understand what a pair of accessor functions have to do with whether or not a.x is private.

Acctually I do not understand why a.x access is backed into language that it always should be accessed ?

If you're asking why a.x must always be public, the short answer is that it doesn't have to be. If TC39 had not adopted the stance of wanting full encapsulation for private fields, then by simply disallowing the existence of a public field with the same name as a declared private field for any given object (as is the case in most languages supporting class), it would be possible to allow a.x to access the only x available on a.

That's not what they chose, and their reasons are sound enough. I don't necessarily agree with the notion of weakening a language to protect against sloppy or bad programmers, but I also cannot find fault in their reasoning. Since TC39 chose full encapsulation, regardless of what the private field definition token looks like, there's no way that the access expression can ever be a.x for a private field.

[ljharb]

@rdking anything that's based on people's possible mental models is an assumption. Assumptions are fine, anything that involves human thought can't truly be objective.

[rdking]

@ljharb

IMO, assumptions have their use. Justification is not among them. This is even more true when designing a very popular, widely used language. But maybe that's just me.

[trusktr]

What if #foo was kept as "hard private" like it already is, and then a new private foo was a softer alternative introduced later (where this.foo can only access one particular instance variable with a certain access level)? Would that be worth having in addition?

[ljharb]

Why? The word "private" is wildly inaccurate if it's not "hard private".

[rdking]

@trusktr Unfortunately, that would introduce confusion in the extreme. To make something like that work, a class wouldn't be allowed to have both private x and #y. You'd be forced to use either one or the other. It's not that it's not possible to do both in the same class, but that invites confusion. There's also the problem that if private is used, it would need to be impossible to add new members to an instance that have the same name as a private member. In short, while it could be done, it just doesn't seem like a good idea to have both notations.

@ljharb

Why? The word "private" is wildly inaccurate if it's not "hard private".

Um... your absolutism is showing. Think about it like this. If I have a letter in my hand, and I successfully keep you from snatching it away, the contents of that letter are private to me. Who cares if you can see it in my hand. This is what private means to most developers. The only ones doing something screwy that violates your idea of private are those who are doing non-language related things like trying to get around sloppy developers who don't maintain proper versions on their shared code. That's not an issue for the language, but for the shared code developers. While I understand that it's still a pretty big issue, I still can't say that it's within the domain of the language itself to fix (unless the language dictates a library format).