proposal-class-fields
proposal-class-fields copied to clipboard
Support for privates in object literals?
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?
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.
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.
Interesting but why separately? it disperses the focus on the member declarations "packaging".