Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Use a keyword (not necessarily private) as a "private this", such that private. is identical to the currently proposed #, but is used similarly to this.

class Point {

    constructor(x = 0, y = 0) {
        private.x = +x;
        private.y = +y;

    get x() { return private.x }
    set x(value) { private.x = +value }

    get y() { return private.y }
    set y(value) { private.y = +value }

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

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


Other possibilities for the keyword include:

  • priv. (same length as "this", but perhaps too short / likely to exist in the wild).
  • privates. (clear that it's like an object of slots, but possibly offensive).
  • __priv__. (familiar to Pythonistas and reminiscent of __proto__, but I don't think that's a good thing).
  • __this__. (I don't like it, but others might).
  • privatethis. (arguably the most instructive, but long and ugly).
  • protected (I don't think this would make sense, but may work if there is specific objection to private).


  • private is already reserved, and would have no other reasonable use.
  • # is the only "free sigil" left on a US keyboard for JavaScript (that I know of) and might be better saved for a feature* which would be used in both application and library code, rather than only library code.
  • It is immediately clear what private. is for; # is not likely to be immediately clear.
  • It would be friendlier to existing language tooling and implementations (eg; syntax highlighters, static analysis tools, and parsers would require minimal/no modification).
  • It is more obvious that private.x and this.x are completely separate, and can peacefully coexist as unrelated fields.
  • It resolves the surprising difference between this.#x and this['#x'].


  • would likely be surprising to a Java or C# engineer, where private is used differently. (I would argue this is similar to the existing self/this differences).
  • private is already implemented in TypeScript, and this would clash. (I would argue TypeScript would likely be able to adapt).
  • private['foo'] would either need to be supported (which I'm not sure is possible/desirable) or explicitly disallowed, which would be surprising. (I would argue that only spec-reading library authors are likely to use this feature, and immediately understand why private[ is not allowed).

Note that the following initialization/declaration syntax is also a possibility:

class Point {
  private x = 0;
  private y;
  // ...

...though that may result in confusion when private.x is accessed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment