Accessing private fields

[yanickrochon]

Header placeholder (I will update this with a summary of the discussion, here).

[yanickrochon]

I do see a problem where this.#x !== this['#x']. AFAIK, using square brackets allow accessing properties that contains reserved keywords and other illegal characters, such as this['foo.bar'] or this['%n items']. There is something wrong that

this.#x = 'foo';
this['#x'] = 'bar';

should be fine and not all confusing. It is not a matter of getting used to, but one that is simply illogical and incoherent.

If a this syntax is adopted, then something should be done to differentiate accessing standard properties and private fields.

Some have proposed this->x but I personally always found it awkward in the C language, and would totally mean something different in JavaScript. It is used in other languages as well, however these languages usually do not use the dot-notation at all to access properties.

Some have proposed only using a sigil (i.e. this#x) but I feel it lacks readability, and does not help making code clear.

Some have proposed a double dot (i.e. this..x) but, among other things, it can lead to unexpected errors where some could make the typo this..toString(), etc.

A single colon (i.e. this:x) is illegal, but what about a double one (i.e. this::x)?

[littledan]

In this proposal, private state is not based on property access. If we use square brackets, the state will no longer be private. The proposal uses .# to allude to property access (it is getting a thing out of it) but to be noticeably distinct and avoid ASI hazards that would come from the abbreviated form #x for this.#x. :: is proposed for the fairly popular "bind operator" proposal. One thing I like about obj.#x is that you can use #x at both the definition and use site, symmetrically.

[yanickrochon]

An idea for a dot-notation implementation

class Foo {
  private x = 123;

  // NOTE: early error "x is already defined"
  // x() { return this.x; }

  getX() { return this.x; }
  setX(x) { this.x = x; }

  setFrom(foo) { this.x = foo.x; }
}

01a : Name collision test

let foo = new Foo();
foo.x;
// -> undefined
foo.getX();
// -> 123

foo.x = "abc";
foo.setX("Hello");

foo.x;
// -> "abc"
foo.getX();
// -> "Hello"

01b : Name collision test (strict mode)

`use strict`;

let foo = new Foo();
foo.x;
// Error : cannot access specified private field

02 : Private field not accessible externally

let foo = new Foo();
let bar = new Foo();

bar.setX("something");
foo.setFrom(bar);
// Error : cannot access specified private field

03 : Private field setting from generic objects

let foo = new Foo();
let bar = { x: "Hello" };

foo.setFrom(bar);
foo.getX();
// -> "Hello"

Implementation

For foo.x, where foo is a context and x a property, and this is the current context.

1. if context contains private property then
   1. if context === currentContext then
      • return ref private property
   2. if context is instanceof currentContext OR in strict mode then
      • throw "Cannot access specified private field"
   3. else
      • return context's defined property ref
2. else
   • return context's defined property ref

Usage

To avoid repetitive checks, it is recommended to place the resulted value in a temporary variable. Such as const x = foo.x;.

Other caching methods may be used to speed up further checks within the same context.

Dynamic access

Since this.something === this["something"], this implementation is fully compatible with accessing private fields dynamically, where property is simply eval'ed first.

Future proof

For any upcoming protected draft, the same rule applies, except that the implementation would be replaced with

1. if context contains private property then
   1. if context === currentContext then
      • return ref private property
   2. if context is instanceof currentContext OR in strict mode then
      • throw "Cannot access specified private field"
   3. else
      • return context's defined property ref
2. if context contains protected property then
   1. if context === currentContext or context is instanceof currentContext then
      • return ref protected property
   2. else
      • throw "Cannot access specified protected field
3. else
   • return context's defined property ref

[chicoxyzzy]

:: is proposed for the fairly popular "bind operator" proposal

AFAIR it won't be :: tc39/proposal-bind-operator#24 (comment) but I could be wrong

[zenparsing]

The bind operator does have a champion (just not me).

[littledan]

I posted an example of a decorator to provide these square bracket indexing semantics in DECORATORS.md. In general, earlier discussion leading up to ES2015 has led us to the conclusion that ordinary property access for private state Just Won't Work, and that's why we're pursuing an alternative in this proposal which is not property access. The use of . is deliberate, so it looks like we're getting at a thing in the object, but you can tell it's not the same because it's followed by a previously-illegal #.