How are reified private accessors represented?

[jridgewell]

I'm not 100% sure where to file this. It's concerns something in between private fields and decorators proposal. It has to do with the reification of the private name, and how accessors are exposed to devs.

Given:

class Ex {
  get #field() {
    console.log('get');
  }
  set #field(value) {
    console.log('set', value);
  }
}

// Now pretend `field` is the reified private name
field.get(new Ex());

Obviously, if I did this.#field it would log 'get'. But if I use the reified private name to get the value, should it? I would hope so. But now how do we represent that this isn't a normal "data" field on the instance, but an accessor? Does the interface of the PrivateName change at all? Would field.get === descriptor.get?

[rdking]

Doesn't the same question exist even without the reified name? Here's a variation of your example that should cause the same question.

class Ex {
  get #field() {
    console.log('get');
  }
  set #field(value) {
    console.log('set', value);
  }
  action() {
    return this.#field;
  }
}

(new Ex).action();

For this to work, wouldn't the value stored in the field always need to be an object? Maybe essentially a property descriptor or some reduced version thereof? If it were, then field.get from your example would just return that descriptor and call get against it.

[ljharb]

Without a means of getting the virtual "property descriptor", there'd be no way to access the raw getter or setter - so a reified private name value would just unavoidably access the getter or setter as expected, much the way array length works.

[jridgewell]

For this to work, wouldn't the value stored in the field always need to be an object?

In syntax only, engines can apply whatever optimizations they want. Because there's no way for syntax to get the actual accessors (only for it to invoke them), they don't really need to be represented in any format.

Without a means of getting the virtual "property descriptor", there'd be no way to access the raw getter or setter

Don't you think that's an issue? It hides that a whole slew of code can be run by a simple this.#foo access. And the accessors become even more privileged than private methods, because they can only be invoked on instances where methods can this.#foo.call(other).

I don't think this is a must have, but definitely something we should be discussing.

[ljharb]

I mean, I'm not a fan of getters and setters at all, for that reason - I think that "a whole slew of code can be run by a simple access" is the ship that sailed in ES5, and there's zero additional issue with it on a private getter method.

[littledan]

In the decorators proposal, this code would invoke the getter. PrivateName.prototype.get calls PrivateFieldGet (which should probably be renamed to PrivateGet) which calls any getters.

[jridgewell]

Ok, so it's still invoking the getter (which it definitely should). We're just not exposing the getter/setter functions at all.

[littledan]

You can access the getter/setter functions from a decorator.

Closing as I think I've answered the question. Feel free to file any follow-on issues in the decorators repository.