Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Support for privates in object literals? #318

Open
dgkimpton opened this issue Aug 25, 2020 · 3 comments
Open

Support for privates in object literals? #318

dgkimpton opened this issue Aug 25, 2020 · 3 comments

Comments

@dgkimpton
Copy link

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
Copy link
Contributor

bakkot commented Aug 25, 2020

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
Copy link
Author

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
Copy link

Lcfvs commented Sep 9, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants