Open dgkimpton opened 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.
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".
I was writing a simple object today and I wondered why private fields are restricted to classes?
e.g.
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.
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?