Private fields are tied to classes

[futpib]

Since class is syntactic sugar for function and "special" "prototype" property (at least class constructors are defined in terms of function and "prototype"), I feel like it's better to tie private fields to those constructs. In other words, one should be able to achieve exactly same results with function and prototype as with a class.

Currently this proposal adds PrivateFieldEnvironment to Execution Contexts and the only defined way to create new PrivateFieldEnvironment is ClassDefinitionEvaluation (that is evaluation of a class ... expression).

This will result in that whenever user wants to create on object with truly private fields, they will have to use a dummy class declaration with all it's limitation (like inability to declare arbitrary class members in runtime in reflective manner (without eval-like features)).

I propose that at least

• a way of creating a new PrivateFieldEnvironment and a way of defining new PrivateFieldIdentifers in that environment in reflective manner are defined
• ObjectDefineProperties (with ToPropertyDescriptor) are altered to allow definition of an object with private fields using Object.create

EDIT: The Object.create part has been revised as unnecessary later in this thread.

[littledan]

This proposal deliberately avoids making private fields a kind of property. That approach was attempted at TC39 in the past, but it leads to the question: If private fields are object properties, then how do Proxies view them? It didn't seem like there was any good answer to the question that preserved the properties that Proxies were intended to have. cc @erights

[futpib]

@littledan Thanks, I get that. I guess what I was really trying to say was that making PrivateFieldEnvironment, PrivateFieldIdentifers and [[PrivateFieldValues]] usable by means other than in class declaration would make private fields more useful.

This does not necessarily mean that existing reflection methods like Object.getOwnPropertyNames or Object.getOwnPropertySymbols should expose private properties. Nor even that there should be special methods like Object.getOwnPrivatePropertyNames specifically for [[PrivateFieldValues]].

But I think making a new universal object slot [[PrivateFieldValues]] exclusively for class declaration is very limiting.

This does not seem to contradict the arguments made in this FAQ entry.

[littledan]

Sorry for misunderstanding your message. I've been thinking about what sort of reflection mechanism we should have for private fields; one draft is in this file. However, I've been thinking about this mostly as it relates to decorators--not use outside of a class.

I don't think it'd be great if people had to go around using imperative, semi-reflective machinery to use private fields outside of classes. It would be nicer if some sort of syntax just works.

For example, we could make the #names be available to everything in the script or module, but not outside of it; then we could allow object literals to have private fields, and reference them from outside of that literal. The downside of this particular idea is that people often concatenate scripts when shipping them, and this concatenation would break the encapsulation; generally, it's nice that JavaScript has this property that you can wrap things in separate IIFEs and they'll stay basically separate, and it would be unfortunate to lose this property.

Do you have another particular idea for how we should enable this feature?

[futpib]

Sorry for being unclear, I see how my objections are vague. My prime motivation for creating this issue after reading the proposal was that adding new slots to objects and especially the execution context to be used only in classes (which are a derived concept themselves) left me uncomfortable since desire for hard encapsulation is not necessarily tied exclusively to classes or OOP. Another thing is the inability to define private properties dynamically/reflectively.

PrivateFieldEnvironment looks like just like the usual lexical environment, except it is used for private identifiers. Very similarly to how lexical environment is used for common identifiers. Unfortunately I can't imagine a really-really nice way to extend this proposal in it's current form to allow general use of PrivateFieldEnvironment, but let me propose the best I got:

function Point () {
  private #x;
  private #y;
  
  const p = {
    #x: 0,
    #y: 0
  };
  
  p.#x; // 0
  p.#y; // 0
  
  return p;
}

I think this is pretty self-explanatory (function declarations get a PrivateFieldEnvironment just like class declarations), but If there is any interest in this, I can try to formalize this.

EDIT: The lack of reflection still bugs me, even though if you view private identifiers like another kind of lexical identifiers, the lack of reflection kind of makes sense.

[ljharb]

Interesting idea! Would the following be the desugaring into WeakMaps?

function Point() {
  const x = new WeakMap();
  const y = new WeakMap();

  const p = {};
  x.set(p, 0);
  y.set(p, 0);

  x.get(p); // 0
  y.get(p); // 0

  return p;
}

[futpib]

Yeap, that's right.

[futpib]

Oops, no, actually, that's not quite right.

The trick is that PrivateFieldEnvironment for classes is created when class definition is evaluated. It's better be the same for functions.

The following desugaring gets this right.

const Point = (function () {
  const x = new WeakMap();
  const y = new WeakMap();

  return function Point() {
    const p = {};
    x.set(p, 0);
    y.set(p, 0);
  
    x.get(p); // 0
    y.get(p); // 0
  
    return p;
  };
})();

But if we want to be really thorough we would replace WeakMap with something like PrivateFieldIdentifier.

[littledan]

@futpib Interesting idea. Do you think this proposal should have any changes to "future proof" for that as a follow-on?

[futpib]

@littledan Is this too major of a change for the proposal at it's current stage? I think something like this should be included with the first landing of private fields (and should have been included from the get-go). If that's not an option, I guess it's future-proof enough for this to be included later.

This fits the JavaScript's class-function duality so nicely >_<

Click to expand large desugaring examples

class Point {
  #x;
  #y;

  constructor(x = 0, y = 0) {
    #x = +x;
    #y = +y;
  }

  get x() { return #x }
  set x(value) { #x = +value }

  get y() { return #y }
  set y(value) { #y = +value }

  equals(p) { return #x === p.#x && #y === p.#y }

  toString() { return `Point<${ #x },${ #y }>` }
}

After desurating class:

const Point = function () {
  private #x;
  private #y;

  function Point(x, y) {
    this.#x = +x;
    this.#y = +y;
  }

  Point.prototype.equals = function equals(p) {
    return this.#x === p.#x && this.#y === p.#y;
  };

  Point.prototype.toString = function toString() {
    return "Point<" + this.#x + "," + this.#y + ">";
  };
  
  Object.defineProperty(Point.prototype, "x", {
    enumerable: true,
    configurable: true,
    get: function get() {
      return this.#x;
    },
    set: function set(value) {
      this.#x = +value;
    }
  });
  
  Object.defineProperty(Point.prototype, "y", {
    enumerable: true,
    configurable: true,
    get: function get() {
      return this.#y;
    },
    set: function set(value) {
      this.#y = +value;
    }
  });

  return Point;
}();

After desugaring private identifiers:

const Point = function () {
  const x = new WeakMap();
  const y = new WeakMap();
  
  function Point(x, y) {
    y.set(this, +y);
    x.set(this, +x);
  }

  Point.prototype.equals = function equals(p) {
    return x.get(this) === x.get(p) && y.get(this) === y.get(p);
  };

  Point.prototype.toString = function toString() {
    return "Point<" + x.get(this) + "," + y.get(this) + ">";
  };
  
  Object.defineProperty(Point.prototype, "x", {
    enumerable: true,
    configurable: true,
    get: function get() {
      return x.get(this);
    },
    set: function set(value) {
      x.set(this, +value);
    }
  });
  
  Object.defineProperty(Point.prototype, "y", {
    enumerable: true,
    configurable: true,
    get: function get() {
      return y.get(this);
    },
    set: function set(value) {
      y.set(this, +value);
    }
  });

  return Point;
}();

[bakkot]

@futpib

Is this too major of a change for the proposal at it's current stage?

Almost certainly. This would be a huge addition, and we've been trying to get class features in for a long time. I would strongly prefer not to add more new things to the proposal at this point.

---

I want to point out a potential conflict with the current proposal:

function Point () {
  private #x;
  
  const p = {
    #x: 0
  };

  class Other {
    #x = 1; // Is this the same '#x' as above?
  }
}

We previously considered (and rejected) declaring private fields in classes as private #x, which would avoid the issue nicely. On the other hand, it would be kind of surprising if private #x were the only declaration legal in both function bodies and class bodies.

[futpib]

@bakkot I thinks the "conflict" you pointed out is not an issue when private identifiers are lexically scoped.

class A {
  #x = 0;

  constructor() {
    class B {
      #x = 0;

      constructor() {
        #x = 1; // lexically closest #x
      }
    }
  }
}

[bakkot]

@futpib It's a conflict in the sense that it's not obvious that {#x:0} references a previously declared name whereas class {#x=0} declares a new one.

[littledan]

Almost certainly.

Hang on, @bakkot; it's not at Stage 3 yet. TC39 has been working on this problem for several years; I really want to see it shipped now too, but let's make sure to keep taking any useful feedback we get.

Anyway, @futpib:

I think the way you're resolving the conflict there makes sense--classes introduce a new scope for these identifiers, as does any block that contains "private #foo", and shadowing works lexically. It all makes sense to me, and seems like a consistent extension of the current proposal. This is actually pretty similar to some ideas that I remember seeing on the ECMAScript wiki, but I don't know where to find that; @allenwb do you remember this? It's really nice to have a story for object literals here, and it would actually be consistent with the destructuring proposed in a different issue. The only concerns I have would be:

• Is the syntax intelligible to users? Both where a new "private name scope" is introduced, and what it means to have declared private names, and the difference between private #x to just declare a name, outside of a class, with #x declaring a field inside of a class?
• It seems like private #x is only used for object fields, unlike the earlier syntax where it was what was used to introduce all private identifiers. Do you think there's a more evocative name possible here?

A good repository to follow up on this further would be the unified class features proposal, which currently assumes that objects' curly brackets will be what sets off the new private name scope.

[bterlson]

Doesn't future proofing for this extension require using private for class declarations now? To illustrate further the hazard @bakkot raises:

private #id;
let instances = 0;
export class A {
  // declare a new private name with same name
  #id = instances++;
}

export function getId(a) {
  // refers to a different name than A's, so will never return an id.
  return a.#id;
}

I'd expect the above to work, though you might expect it to work even with a private keyword before the class declaration. Errors on private name shadowing could mitigate this somewhat.

[littledan]

@bterlson, Would you expect the following example to work (apologies for the horrible names)? Maybe if you come with a Java-like intuition, and you expect such a reference to be disambiguated, you would. The current proposal, though, expects that users can understand what it means for a private name to be shadowed.

Do you think if we introduced the keyword private, it would create the false intuition that that's the only place where a new name binding is created, but without ever creating that syntax, it's more clear that shadowing works the way it's currently proposed?

class Button {
  #id = MakeGUID();
  labelFactory() {
    let button = this;
    return class Label {
      #id = MakeGUID();
      getButtonID() {
        return button.#id;
      }
    }
  }
}