Yet another approach to a more JS-like syntax

[zocky]

I realize I might be beating a dead horse, but it seems to me that I'm far from being the only one who intensely dislikes the use of # for private fields/methods. So here goes:

1. Use the private keyword to introduce private field, methods, setters, getters, exactly as with static.
2. Use bare field and method names without any qualifiers to access private fields and methods within the class's methods, just like we do now in factory functions, i.e. treat them like variables.
3. Use private.name to explicitly access the private fields of this object, if there are conflicting names, just like we do with super. Also use private["name"] for non-ident and calculated field names.
4. Use private(otherObject).name or private(otherObject)["name"]to access the private fields of another object of the same class. For symmetry, private(this).x is the same thing as private(this)["x"] private.x or private["x"] or just x if there's no variable x in scope.
5. In methods, private and private(otherObject) are not valid constructs without being followed by .field or ["field"] and throw syntax errors.

AFAICT, this achieves all the requirements, without introducing a wildly asymmetrical new syntax for private fields, AND gives us a natural way of reading code in human language, solving the naming problem that was brought up on other threads.

[littledan]

Use bare field and method names without any qualifiers to access private fields and methods within the class's methods, just like we do now in factory functions, i.e. treat them like variables.

We've been a bit hesitant to go for proposals like this, as it could be seen as a confusing extension to lexical scope. See zenparsing/js-classes-1.1#18 for related discussion.

Use private.name to explicitly access the private fields of this object, if there are conflicting names, just like we do with super.

Similarly, we've been hesitant to add further structures which implicitly reference this, as it's already hard enough for people to figure out this in debugging.

Use private(otherObject).name to access the private fields of another object of the same class. For symmetry, private(this).x is the same thing as private.x or just x if there's no variable x in scope.

In this case, what would be the value of private(otherObject)? Would it require a literal . after it?

One concern I have about this proposal is that, if you forget to reference things through private and just use ., your code will all work (modulo initializers), just that everything will be public. Making # part of the "name" makes this hazard less likely.

[zocky]

We've been a bit hesitant to go for proposals like this, as it could be seen as a confusing extension to lexical scope. See zenparsing/js-classes-1.1#18 for related discussion.

IMO, it's no more confusing than the fact that other syntax inside a class definition works differently than outside of it. And for beginners, it's probably less confusing than a closure. Anyway, it is exactly what we most commonly do now with factory functions when we want to have the equivalent of private fields.

Similarly, we've been hesitant to add further structures which implicitly reference this, as it's already hard enough for people to figure out this in debugging.

I don't understand this concern. It's exactly the same as with other things that already exist. How is private.foo() more confusing than super.foo()?

In this case, what would be the value of private(otherObject)? Would it require a literal . after it?

Yes. It's not a function call, it's a construct. And it wouldn't be the only one that looks vaguely like a function call, but actually isn't. We don't expect if(...) or for(...) or while(...) after a do block to work or parse exactly like function calls, even if they look vaguely similar.

[zocky]

One concern I have about this proposal is that, if you forget to reference things through private and just use ., your code will all work (modulo initializers), just that everything will be public. Making # part of the "name" makes this hazard less likely.

But you don't actually do that in this proposal. this.x is not the same thing as private.x, and can never be accessed using the same syntax.

[zocky]

I've added a clarification above.

[zocky]

Another thought - the idea that private and public fields should not be in the same namespace (which I follow in this proposal) isn't necessarily wrong, but it does make a very common use case (change a field from public to private or vice versa) a menial and error-prone task, unlike in other languages where it consists of just adding or removing the private keyword in the class definition.

[mgtitimoli]

I was pleasantly surprised about this other way proposed by @zocky, I hope it will get a lot of attention, as it's a really clever and clean way of solving this issue.

[mgtitimoli]

I might agree with avoiding the implicit way of using private members, but for the other way, this is, the explicit one, using private not only for defining, but also for accessing them is a clear goal, as it introduces only one keyword to do everything, and allows using the square bracket notation without having to prefix the identifier with any other symbol which is also something really desirable.

On the other hand, the fact it shares a lot of similarities with how super is used, reduces a lot the learning curve required to make use of this new feature at the same time that it clearly simplifies the amount of stuff needed to teach this to newcomers.

And last but not least, it translates 1 to 1 with a possible "private" function that receives an instance and returns the previously stored "private" properties in a WeakMap, which makes this way super easy to teach and understand as it can be constructed with other existent primitives almost directly.

I'm talking about the following example which could be easily refactored using this new syntax just by removing all the helpers, the constructor (it would be super nice to allow initializers too 🙂), and renaming priv to private.

const privByInstance = new WeakMap();

const initPriv = (instance, members = {}) => privByInstance.set(instance, members);

const priv = instance => privByInstance(instance).get(instance);

export default class MyClass {
  constructor() {
    initPriv(this, {privA: "A", privB: "B"});
  }

  get privA() {
    return priv(this).privA
  }
}

[bakkot]

The FAQ is intended to address this proposal, which has come up a couple of times. As it says, the main thing for me is that private x for declaration without this.x for access seems like it would be a giant footgun.

[mgtitimoli]

So @bakkot you find private.x for accessing private members not enough clear?

[zocky]

As it says, the main thing for me is that private x for declaration without this.x for access seems like it would be a giant footgun.

Is this a technical objection, or just a matter of taste?

Edit:
We also declare static fields with static x but can't access them with this.x, but rather have to use this.constructor.x. (It would be nice if we could access them with static.x, but that's a matter for a different discussion.)

[mgtitimoli]

As far as I can see, none of the items expressed in the FAQ explores the way expressed here, and in the other hand and IMHO if at the time of designing the way super is used, the committee resolved that's clear and easy to understand, then the mechanisms expressed here should surprised anyone.

[mgtitimoli]

FTR: I've just shared this issue in JS Classes 1.1 Proposal as IMHO it addresses in a clean and understandable way the main topics that made that other proposal to emerge.

[bakkot]

@mgtitimoli, @zocky, to be specific: I think any proposal which allows

class A {
  private field;
  constructor() {
    this.field = 0;
  }
}

to create an object with a public field holding 0, is unacceptably confusing. This is true no matter what the syntax for accessing the private field is, as long as it is not this.x (which it can't be for reasons also given in the FAQ).

I think this is a very important constraint, which is why it is the first question in the FAQ.

static doesn't bother me because people familiar with other languages will not be misled about which object gets the field.

Is this a technical objection, or just a matter of taste?

I don't really understand the distinction. My concern is not that I find it personally distasteful but rather that I find it misleading, if that's what you're asking.

[mgtitimoli]

@bakkot I noticed you mentioned this way in your previous message, just to be all aligned, what @zocky proposed is to access private members using the following construction:

private.field = 0;

and not

this.field = 0;