proposal-class-fields icon indicating copy to clipboard operation
proposal-class-fields copied to clipboard

Support for privates in object literals?

Open dgkimpton opened this issue 5 years ago • 3 comments

I was writing a simple object today and I wondered why private fields are restricted to classes?

e.g.

function make(name, ssnP) {
   return {
      name,
      validateUser(expectedSSN) {
         return ssnP === expectedSSN;
      },
  };
}

This works by closing over the ssn, but it seems that using the private-fields syntax we could make it much more explicit and not require any closure to be created.

function make(name, ssnP) {
   return {
      name,
      #ssn: ssnP,
      validateUser(expectedSSN) {
         return this.#ssn === expectedSSN;
      },
  };
}

However, if I understand the proposal correctly, this wouldn't be allowed because the object isn't defined using 'class'.

I'm curious why this is?

dgkimpton avatar Aug 25 '20 13:08 dgkimpton

In part just because of the history of the proposal: classes are the place where private fields were most obviously important (since you cannot easily substitute a closure for the same effect) and where the semantics were the most straightforward to reason about.

However, there's a followup proposal which would allow you to declare a private field in any scope and then use it in object literals: https://github.com/tc39/proposal-private-declarations

we could make it much more explicit and not require any closure to be created

To be clear, I don't think that's particularly a goal; JS has lots of closures and I don't think avoiding them is a goal in itself.

bakkot avatar Aug 25 '20 15:08 bakkot

Ah right, that makes sense - thanks for the education. That follow-on proposal is all sorts of weird though, I think I'll steer clear of that.

The avoidance of closures was definitely not the primary reason I was asking, more the explicitness of saying 'this is a member, and it's private' instead of the implicitness of closure or the trust of _member. Coding is after all mostly about communicating intent.

It's not the end of the world, _member is pretty well accepted, so really it's more a nice to have.

dgkimpton avatar Aug 29 '20 15:08 dgkimpton

Interesting but why separately? it disperses the focus on the member declarations "packaging".

Lcfvs avatar Sep 09 '20 03:09 Lcfvs