Make # an object on the instance

[shannon]

Update at bottom of description

After reading through the FAQ and issues on the various related repos regarding the sigil I just wanted to run something else by the champions of this proposal.

Please forgive me if this has already been discussed but as I said there are various repos and lots of threads so I may have missed it.

I'm wondering if just making # be a an object property of this makes this proposal more consistent with existing paradigms in Javascript.

For example:

class {
  private x = 'x';

  method() {
    console.log(this.#.x);
  }
}

Would be sugar for:

(function(){
  const __private__ = new Weakmap();
  return class {
    constructor(){
      __private__.set(this, {
        x: 'x'
      });
    }

    method() {
      console.log(__private__.get(this).x);
    }
  }
})();

Why?

Well I get the need for the # sigil for assesor efficiency but there are a couple of points of this proposal that I find unnessarily restricitve.

1. No variable accessors (e.g. this['#x'] or this[somevar]). This would seem like any use case where you would need this for public properties could also be applied to private properties.
2. No private property iteration. To me there shouldn't be any reason I shouldn't be able to iterate over private properties without breaking encapsulation. I can think of one use case in particular for a ECS game engine I am working on.
3. No destructuring. To avoid having to type this.# repeatedly it would be nice to be able to use destructuring at the beginning of a method to access private properties.

With this adjustment all of these should be possible without losing any encapsulation.

Variable accessors:

class {
  private x = 'x';
  private y = 'y';

  method() {
    const prop = condition ? 'x' : 'y';
    this.#[prop] = somecomplexcalc(this.#[prop]) ; 
  }
}

vs

class {
  #x = 'x';
  #y = 'y';

  method() {
    if(condition) {
      this.#x = somecomplexcalc(this.#x);
    } else {
      this.#y = somecomplexcalc(this.#y);
    }
  }
}

Private property iteration:

class {
  private x = 'x';
  private y = 'y';
  private z = 'z';

  method() {
    for(const [prop, value] of Object.entries(this.#)){
        this.#[prop] = somecomplexcalc(value);
    }
  }
}

vs

class {
  #x = 'x';
  #y = 'y';
  #z = 'z';

  method() {
    this.#x = somecomplexcalc(this.#x);
    this.#y = somecomplexcalc(this.#y);
    this.#z = somecomplexcalc(this.#z);
  }
}

Destructuring:

class {
  private x = 'x';
  private y = 'y';
  private z = 'z';

  method() {
    const { x, y, z } = this.#;
  }
}

vs

class {
  #x = 'x';
  #y = 'y';
  #z = 'z';

  method() {
    const x = this.#x;
    const y = this.#y;
    const z = this.#z;
  }
}

Why private in declaration? (I know it's been talked about but I have to try)

First consistency and readability:

class {
  #x = 'x';
  @protected #y = 'y';
  static method (){}
}

vs

class {
  private x = 'x';
  protected y = 'y';
  static method() {};
}

Secondly, with # being a property of this instead of part of the name of the property it makes more sense here.

Conclusion

To me, this makes this proposal seem a little less strange compared to the rest of Javascript. It's a simple mental model. All private properties are stored on this.# which is only accessible from within the class methods.

Keeping the sigil for accessors means it's non breaking for any existing code so I'm ok with it there but I really hope we reconsider using private in the declaration just to keep the syntax consistent and readable.

Edited: typo and broken formatting in github

Updated proposal

I wanted to provide an update to my proposal based on the discussions in the thread. I believe that the # should be moved to before this to make it clearer to developers that #this is a lexically scoped variable.

class {
  private x = 'x';

  method(obj) {
    console.log(#this.x, #obj.x);
  }
}

Would be sugar for:

(function(){
  const __private__ = new Weakmap();
  return class {
    constructor(){
      __private__.set(this, {
        x: 'x'
      });
    }

    method(obj) {
      console.log(__private__.get(this).x, __private__.get(obj).x);
    }
  }
})();

I have also taken the comments of @ljharb and @bakkot into consideration and I have a further addition that will prevent any leakage to mutations.

To avoid any leakage we can make it a syntax error to assign #this to any variable, property, return value, or function parameter. This is actually a really simple syntax check. # must be immediately followed by variable identifier which must be immediately followed by a . or [. With the only exception being for destructuring.

Syntax error example:

const x = #this;
const x = { #this };
const x = { x: #this };
const x = [#this];
somefunction(#this);
return #this;

I'm sure there tons I have missed here but as long as they follow those rules there shouldn't be any leakage.

Valid syntax examples:

const x = #this.x;
#this.method();
#this.x++;
#this['x']++;
const { x } = #this; // exception to the rule but doesn't cause leakage
const x = { ...#this }; //exception to the rule but doesn't cause leakage

This prevents any leakage for mutations.

This doesn't fully address the issue with private keyword implying this.x access but I think it comes pretty close.

Edit: I accidentally left out or [ syntax check that I had in my notes here

[ljharb]

What would the [[Prototype]] be for this object? Would i be able to pass it around and expose private values to mutation later, perhaps by accident as the receiver with this.#.foo()? Would i be able to install getters and setters on this.#?

[bakkot]

See this recent thread on computed property access and iteration.

Re: the syntax for declaration, I am strongly opposed to any proposal which has private x as the declaration and does not have this.x for access for the reasons given in the FAQ.

There's some other issues with this suggestion which I can go into detail about if you'd like, but these are some of the major points.

[shannon]

@ljharb

What would the prototype be for this object? Would i be able to pass it around and expose private values to mutation later, perhaps by accident as the receiver with this.#.foo()? Would i be able to install getters and setters on this.#?

Sure just as you could break encapsulation now by accidentally passing any enclosed object around. Accidentally passing this.# seems pretty unlikely to me. Is there some reason that I'm not seeing as to why we wouldn't want to allow getters and setters?

@bakkot

See this recent thread on computed property access and iteration.

I've read that thread, I'm not sure I understand completely the opposition in the context of my suggestion. this.# should only be able to be referenced from within the class methods. If the suggestion in that thread is to place the private properties into a private map, how is that any different than my suggestion?

As you can see from my examples in the description, there are very common use cases for being able to reference a private property from a variable. If this is prohibited then it's going to lead to a lot of ugly
and redundant code.

Re: the syntax for declaration, I am strongly opposed to any proposal which has private x as the declaration and does not have this.x for access for the reasons given in the FAQ.

I've read the FAQ but it doesn't really give a convincing argument. The same could be said accidentally using this.x instead of this.#x. As many times as it's been said throughout these threads that other languages shouldn't be used as a measurement for this proposal I have to say assuming this.x access of a private field because other languages do fails under the same logic.

[shannon]

@ljharb Not sure why you would but if you want to prevent getters and setters from being added later you can use Object.seal.

(function(){
  const __private__ = new Weakmap();
  return class {
    constructor(){
      __private__.set(this, Object.seal({
        x: 'x'
      }));
    }
  }
})();

[bakkot]

@shannon

If the suggestion in that thread is to place the private properties into a private map, how is that any different than my suggestion?

The suggestion is that you should use a private property with a Map if you for some reason need a private map, not that you should always do this. I would prefer to encourage the mental model that private properties are record-like.

As you can see from my examples in the description, there are very common use cases for being able to reference a private property from a variable.

I do not share your intuition that these are very common uses cases for private fields.

If this is prohibited then it's going to lead to a lot of ugly and redundant code.

I don't share this intuition either - I don't think putting an object on a private field is all that ugly, and it seems to me it would satisfy your use cases without particular redundancy. In fact, if you had #_ = { x: 'x', y: 'y' } in the class body under the current proposal, you could use this.#_.x or this.#_['y'] for access to get almost identical syntax to what you're asking for without requiring reifying and reasoning about an actual object for the more common record-like use case.

I've read the FAQ but it doesn't really give a convincing argument. The same could be said accidentally using this.x instead of this.#x. As many times as it's been said throughout these threads that other languages shouldn't be used as a measurement for this proposal I have to say assuming this.x access of a private field because other languages do fails under the same logic.

I'm sorry you don't find the argument convincing. I do. I am less concerned (not unconcerned, but less) about this.x vs this.#x because of the symmetry between declaration and use, which is shared by public fields: class C { x = 0; #y = 1; m(){ return this.x + this.#y; } } is very consistent, to my eye.

Also, we do care what happens in other languages and would prefer to avoid misleading people with a background elsewhere, especially in cases where there is very similar syntax which has significantly different semantics in another language. We don't necessarily want to replicate other languages identically (and often are not in a position to in any case), but that doesn't mean we feel free to totally ignore them.

[shannon]

@bakkot

I would prefer to encourage the mental model that private properties are record-like.

If we want a record-like syntax than it shouldn't be accessed via this at all (i.e. this.#x or this.x or this.#.x). It should just be blocked scoped and accessed via bare x. A mental model that all javascript developers are familiar with. Yes, I have read the FAQ on bare x but it seems to me that we've decided on trying to pick and choose from two different paradigms and ended up with something that is pretty inconsistent with the rest of javascript.

In fact, if you had #_ = { x: 'x', y: 'y' } in the class body under the current proposal, you could use this.#.x or this.#['y'] for access to get almost identical syntax to what you're asking for without requiring reifying and reasoning about an actual object for the more common record-like use case.

Having to do #_ = {...} is not exactly pretty. But more importantly without a proposal implementation to sort out context for private methods it becomes really messy really quick.

class {
  x = 'x';
  #y = 'y';
  #_ = {
    method () {
      //how do I even reference x and y?
    }
  }
}

vs

class {
  x = 'x';
  private y = 'y';

  private method () {
    return this.x + this.#.y;
  }
}

Being sugar for something like:

(function(){
  const __private__ = new Weakmap();
  const __methods__ = {
    method: function() {
      return this.x + __private__.get(this).y;
    }
  }
  return class {
    constructor(){
      __private__.set(this, {
        y: 'y',
        method: __methods__.method.bind(this)
      });
    }
  }
})();

[EthanRutherford]

@bakkot it seems your biggest complaints against this proposal are this:

1. inconsistency between declaration and access.
2. the ability to accidentally expose private parts.
3. private access should always be thought of as "record-like"

I personally think that (with some small tweaks) this proposes a much less complicated, easier to understand implementation of privates, without really deviating too far from what's already in the main proposal.

This would essentially be the same as the current implementation, except with only one private member, named simply #, as opposed to infinitely many prefixed with #.

To address concern # 1, the following would provide consistent declaration and access:

class Foo {
    x = "I'm pubic"
    # = {
        y: "I'm private",
        method = () => this.#.x + this.y;
    }
}

This to me seems much easier for the uninitiated to comprehend. Rather than explain "Oh yeah, well a member prefixed by # means that the member is private. Except that really, it's not a member at all anymore. You can write a new member at any point, but privates all have to be declared up front in the class body. Also the name isn't #foo, it's actually just foo, but you have to use the # sigil to differentiate between public and private members. They're also not dynamically accessible, or iterable...."
You get the point. It's a drastic break from what we're used to with js classes (or js anything, for that matter), and takes some effort to explain.

With this, the explanation is a lot simpler. "this.# is the private object. Put anything you want to keep private in there.". It intuitively makes sense. Sure, there's this one special property that behaves different, but it's just one, and it gets to be special because it's the private object. And you can write whatever you want into it, iterate it's properties, etc.

(This has another nice parallel to how react state is usually declared and used, just to put that out there.. state = { foo: 1 }, method = () => this.state.foo + 3)

For concern # 2, I don't know that this is any more potentially dangerous than what is already possible. Sure, you could accidentally leak some information, but any potential for leak would also be present in the current implementation, via this.#_ = {}.

As for # 3, I really don't think correct to say that privates should only be record-like, or even to encourage users to only think of privates as record-like. Sure, the use cases for dynamic access and iterability are not the most common cases, but they certainly aren't non-existent. I don't see any value to treating private values as record-only. To the contrary; I think that having them be so, when the reasons why they are are so technical and non-obvious, creates a very strange limitation that breaks the user's intuition about how the language should work. When a user asks "why can't I iterate over private properties?" or "why can't I access this dynamically?" the discussion that will follow will be lengthy, and a tad unconvincing. The sheer number issues (and comments) coming up in this repo to the tune of "I read all the FAQ, and much of the conversation, but I still think it would be better to do ___" should be proof enough of that. Despite there being logical explanations for the choices made thus far, the community at large finds the reasoning dissatisfying. There's a general air of "I get it, but that doesn't mean I have to like it."

As such, I feel like it's much easier to swallow having only one private member (an object named #). Just one exception to the rule of property access, as opposed to a giant bag of arbitrarily named exceptions. You don't ever have to worry about what types of access are available for something private. With this.#foo, it almost feels like this is two separate objects, from different languages entirely. You put the funky sigil in there and you're whisked away to a foreign land where property access is completely different than everything you know.
But with this.#.foo (or perhaps even #.foo, why even need the this at this point?) you're just accessing a property of a plain old javascript object. It's comfortable and familiar. It behaves the way you expect it to (the way all javascript objects behave).

I apologize if any of this comes off as combative or stubborn. I don't really have any major technical arguments against the proposal as-is, other than the aforementioned feeling of "I get it, but that doesn't mean I have to like it". For better or for worse, whatever design is eventually accepted into javascript, we will be stuck with forever. I just want to make sure that we truly exhaust all our options before settling on a design. It would be a shame if a feature as highly desired as private data finally arrived, but was generally found to be unpleasant to work with, and confusing to new users. Before committing to any one design, we need to try to be absolutely sure that there truly is no better option.

[shannon]

@EthanRutherford I'm ok with this adjustment. Looks clean and simple to me. I also prefer just #.x. The only ambiguous part is the arrow functions. I'm not entirely sure how they behave with class properties to begin with.

I would have written it like this:

class Foo {
    x = "I'm pubic";
    # = {
        y: "I'm private",
        method() { return #.y + this.x; }
    }
}

How will this behave with the proposal as it is?

class Foo {
    x = "I'm pubic";
    y = () => { console.log(this.x);  }; //what is the context of this here?
}

*Edited for clarity

[EthanRutherford]

That one is simple. Arrow functions are lexically scoped, so the this of method y in your post would be the instance of the class.

class Foo {
    bar() {
        const test = () => this;
        console.log(test());
    }
    baz() {
        const test = {
            me: () => this,
        };

        console.log(test.me());
    }
}

new Foo().bar(); // output: Foo {}
new Foo().baz(); // output: Foo {}

Just as in the functions above, arrow functions declared this way would have a this lexically bound to the class instance. So, the following methods would both work intuitively.

class {
    x = "I'm public";
    y = () => this.x;
    # = {
        z: () => this.x,
    }
}

[littledan]

This proposal is very interesting, though I share many of @bakkot's concerns. It seems to me like it could be added on top of the existing proposal as a follow on, driven by eexperimentation in transpilers. What do you think, @shannon?

[shannon]

@littledan I would agree with that. It almost feel like a special case for a blank '#' property. It removes the need to use #_ and if it handles the context within methods that would solve all my requirements.

I prefer the syntax

class Foo {
  # = {
    methodX() { ... }
    async methodY () { ... }
  }
}

over

class Foo {
  # = {
    methodX: () => { ... },
    methodY: async () => { ... }
  }
}

But if it's easier because of the lexical scoping as @EthanRutherford described then I would be ok with it.

[bakkot]

@EthanRutherford, I don't think your design would work the way you wanted to, unless it actually did mean something very different from what it appears to.

In particular, I think that in

class C {
  # = {
    getThis() {
      return this;
    }
  };

  receiverIsPrivateObject() {
    return this.#.getThis() === this.#;
  }

  receiverIsObject() {
    return this.#.getThis() === this;
  }
}

(new C).receiverIsPrivateObject();
(new C).receiverIsObject();

it must be the case that receiverIsPrivateObject holds and receiverIsObject does not.

There's a few reasons for this. The most important is that this is how it would work if you used a public field (e.g. if you s/#/_/g above), and if it works differently for #, then it is not just a regular object: it's this weird other thing that looks exactly like an object but has different semantics. Less significantly, but also important, if methods in the object came pre-bound it would mean they couldn't be rebound. Plus it creates a weird asymmetry between # = { m(){} } and # = { m: function(){} }.

So I don't think you can really get the semantics you want, here.

But that means that it's pretty awkward to use: you can't readily refer to a public field from the private object, etc.

I really do not think that reifying an actual object distinct from the instance where private state lives is a good design. I think it's a lot nicer all around to have private state live on the instance, just as it does in other languages.

This to me seems much easier for the uninitiated to comprehend. Rather than explain "Oh yeah, well a member prefixed by # means that the member is private. Except that really, it's not a member at all anymore. You can write a new member at any point, but privates all have to be declared up front in the class body. Also the name isn't #foo, it's actually just foo, but you have to use the # sigil to differentiate between public and private members. They're also not dynamically accessible, or iterable...."

See, this hasn't been my experience at all. I explain to people "to declare a private field, begin its name with #". Sometimes I add that it's like how they might previously have begun its name with _ to suggest privacy, except the language will enforce it. And that's pretty much the whole explanation! People get it just fine. Yes, there's difference about iterability and so on, but these really don't come up that much and tend to be covered pretty well by "oh, right, it's private". I think the whole "private object" thing would be a lot more confusing.

As an aside, I'm not sure what you mean by "also the name isn't #foo, it's actually just foo". I would encourage thinking of the # as part of the name; this comment is certainly not something I would include in my explanation. The only way the language has any notion of what the name of a field is apart from how it's accessed is by function name inference, but #f = function(){} will create a function with .name "#f".

[EthanRutherford]

I think you misunderstand me. No, I don't intend for this object to have any exotic behavior: it will behave exactly the same as an object assigned to #_ under the current proposal. And I entirely disagree: it is not particularly awkward to access other fields from the object. Use an arrow function.

class {
    x = 5;
    # = {
        y: 10,
        // accessing both the public and the private members,
        // in exactly the way that intuitively makes sense
        z: () => this.x + this.#.y,
    };
}

In this way, there is absolutely no confusing behavior or usage: it's just a plain javascript object. I don't see any way this is more confusing, and in fact is largely identical to the way people have been making their own implementations of private data using WeakMaps.

// some-module.js
const privates = new WeakMap();

class Foo {
    constructor(x) {
        privates.set(this, {x}); // initialization of private data
    }
    method(that) { // access of private data, including from another instance of Foo
        return privates.get(this).x - privates.get(that).x;
    }
   // it is trivial to show that I can dynamically access, write, and iterate over private data as well
}

Also, you could just say "to declare a private field, begin its name with #", but you'd also be lying (or at the very least, withholding the truth). Because the truth is, it doesn't behave like like other fields. Calling these private fields, without also being up front about the fact that their access and write semantics are entirely different is deceptive. We're going to end up with people trying to do things like iterate through the private members, access private members dynamically, write new private members at will within methods, and even dynamically write new private members and these things won't work, and it won't be immediately obvious why. In order to explain how private members work, you need to explain all of it.

And I really doubt anyone is going to encounter not being able to iterate through or write new private members and think "ah yes, that makes sense, because they're private". There's no immediately obvious reason that there can't be a private way to iterate through private members. There's certainly no obvious reason I can't add a new private member in a method, either. I can understand the technical reasons, having read much of the discussion here, but I highly doubt that anyone unaware of the implementation details of private members will be able to make those connections.

As to the naming comment, it was my assumption that the sigil would not be parsed as part of the identifier token (# is not a valid identifier character, after all) and would be parsed instead as a symbol or operator token, indicating that the following identifier should be looked up from the private slots, rather than using the standard property lookup.

But the biggest issue with the name is that this would be an unprecedented change to identifiers. There is nowhere else in all of javascript where the way you name a value impact behavior or meaning. This is not only adding a new concept to javascript, but a concept that fits in with nothing else in the language.
Using the lone #, however, we could even treat the sigil as an operator. .# would be an operator meaning "get the private object for this object", whit #.foo still being shorthand for this.#.foo. This would also make a babel transform fairly simple to implement, using an object stored in a WeakMap, providing a far less compicated parallel to what is already possible in JS. Having a reference to the pre-privates-javascript way to do private data greatly simplifies the explanation.

Is there even a parallel to the proposal as-is in JS? Is it even possible (without excessive overhead) to transform a class with private members into current-JS, with full spec compliance?

[bakkot]

I think you misunderstand me. No, I don't intend for this object to have any exotic behavior: it will behave exactly the same as an object assigned to #_ under the current proposal.

Ah, yes, I was conflating your proposal with @shannon's, sorry.

And I entirely disagree: it is not particularly awkward to access other fields from the object. Use an arrow function.

Since classes as they exist currently only allow methods, not arrows, I disagree with you about how awkward this is.

In this way, there is absolutely no confusing behavior or usage: it's just a plain javascript object. I don't see any way this is more confusing, and in fact is largely identical to the way people have been making their own implementations of private data using WeakMaps.

Again, I disagree about how confusing it is to have an object's private fields be properties of a different object.

Also, you could just say "to declare a private field, begin its name with #", but you'd also be lying (or at the very least, withholding the truth). Because the truth is, it doesn't behave like like other fields.

Mm. I disagree that failing to explain every piece of the semantics of something constitutes lying, and have not found most people to be confused by the behavior of private fields. This because private fields behave a great like other fields except that they are private. There are of course details to what that means exactly, but that alone seems to give people an extremely good idea of how they work and let them get on with writing code. If they're interested in how privacy is enforced, I will tell them that it's enforced by the name of the field only being available within the lexical scope in which it was declared, and this name being the only way to refer to the field.

People have been teaching a pattern of creating "private members" with privacy enforced by lexical scope for a decade. These likewise do not show in iteration, cannot be created dynamically, etc. I don't think I would call Crockford a liar, here. And the expectations to which you allude don't seem to have meant people avoid teaching this pattern, even to absolute novices.

I do not share your beliefs about how people tend to expect private fields to behave.

I highly doubt that anyone unaware of the implementation details of private members will be able to make those connections.

Well, quite a few of the people to whom I have explained private fields as above have made those connections, so "anyone" is overstating your case, I think.

As to the naming comment, it was my assumption that the sigil would not be parsed as part of the identifier token (# is not a valid identifier character, after all) and would be parsed instead as a symbol or operator token,

Yes, it's not a valid identifier character. I don't understand why this means it isn't part of the name from the point of view of the programmer. If your concern is people thinking about implementation details - well, in the spec there is a production called PrivateName, which includes the #.

There is nowhere else in all of javascript where the way you name a value impact behavior or meaning.

__proto__ and constructor spring immediately to mind, but that aside: yes, this is new syntax. In my experience it has been very easy to explain its behavior, so while the lack of precedent is a concern, it doesn't seem to me that it ought to be a blocking one.

Having a reference to the pre-privates-javascript way to do private data greatly simplifies the explanation.

I contend that to the extent there is a "the" pre-privates-javascript way to do private data, it is the pattern based on lexical scope I refer to above. I further contend that said pattern is much closer to this proposal than to a new notion of a "private object".

Is there even a parallel to the proposal as-is in JS? Is it even possible (without excessive overhead) to transform a class with private members into current-JS, with full spec compliance?

Yes, with WeakMaps very much like what you're doing. It's awkward and you might debate what counts as "excessive overhead", but it's doable and matches the spec precisely, as long as you're careful about receivers. You can either use a single WeakMap, as you have, or have one per field, as babel is doing.