Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private props #47

Closed
dy opened this issue Mar 29, 2020 · 6 comments
Closed

Private props #47

dy opened this issue Mar 29, 2020 · 6 comments

Comments

@dy
Copy link

dy commented Mar 29, 2020

Private fields are Stage3 proposal, supported by major browsers https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Class_fields. Any plans to support it?

@evanw
Copy link
Owner

evanw commented Mar 31, 2020

Yes, definitely. I will support this at least as a pass-through transformation, and maybe also with a lowering pass (using WeakMap like TypeScript). Just haven't gotten to it yet.

@Sceat
Copy link

Sceat commented May 4, 2020

I'd too love this feature

@evanw
Copy link
Owner

evanw commented Jun 7, 2020

Small update: the private name syntax can now be parsed in the latest release (version 0.4.9). I haven't implemented the transform for older browsers yet, however.

@evanw evanw closed this as completed in 07b1218 Jun 21, 2020
@evanw
Copy link
Owner

evanw commented Jun 21, 2020

This should be working as of esbuild version 0.5.7. I have added support for all kinds of private names (fields, methods, and getters/setters both non-static and static, including interactions with optional chaining). Please try it out and report bugs if you find any.

@toji
Copy link

toji commented Jun 24, 2020

Given that the readme goes out of it's way to point out how slow WeakMap can be I'm curious what other approaches were evaluated? One pattern that I've seen for private fields is to use Symbol, like so:

const privateField = Symbol("MyClass/privateField");

class MyClass {
  constructor() {
    this.publicField = 0;
    this[privateField] = 1;
  }
}

Some quick benchmarking show that this performs closer to regular fields than the WeakMap approach. I know that it's observable via use of Object.getOwnPropertySymbols(), however, which may be the reason enough to avoid this approach if esbuild requires strict semantic equivalence.

@evanw
Copy link
Owner

evanw commented Jun 24, 2020

Some quick benchmarking show that this performs closer to regular fields than the WeakMap approach. I know that it's observable via use of Object.getOwnPropertySymbols(), however, which may be the reason enough to avoid this approach if esbuild requires strict semantic equivalence.

Yes, I have considered that too, but I avoided it for the reason you mentioned. Turning private fields into something that's not private seems like an invalid transformation to me. I could see it being an opt-in transform perhaps.

Part of my hesitation is I've never seen this feature actually used in real-world code. If this feature makes it into more real-world code and 99% of the uses out there don't actually have to do with privacy, then I could see changing the default transformation and have privacy be opt-in instead. But I think it remains to be seen how this feature will actually be used once it gets more wide-spread adoption.

Edit: I see that Babel has a loose option that does this, so it's not without precedent. It would be interesting to hear from others that are using this feature in their code what they are using it for and why they are using it.

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

No branches or pull requests

4 participants