You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.
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.
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.
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.
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?
The text was updated successfully, but these errors were encountered: