tc39 / proposal-class-fields

Orthogonally-informed combination of public and private fields proposals
https://arai-a.github.io/ecma262-compare/?pr=1668
1.72k stars 113 forks source link

Support for privates in object literals? #318

Open dgkimpton opened 4 years ago

dgkimpton commented 4 years ago

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?

bakkot commented 4 years ago

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.

dgkimpton commented 4 years ago

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.

Lcfvs commented 4 years ago

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