-
Notifications
You must be signed in to change notification settings - Fork 3
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
Naming #1
Comments
Can you clarify how this differs from |
@bmeck This idea go from syntax dispute Async Class. My syntax just simple to avoid this argument. And we can do constructor - async default:
|
@Dimtime this proposal might cover things outside the constructor like fields. I'm not sure that argument is really relevant if we continue to find things outside the constructor that would be good to support. E.G. async class X {
foo = await connect();
} |
@bmeck for me Async Class is fine and support fields is good.
When we must await them? Or dont support? |
@Dimtime at stage 1 I have no strong feelings on the eventual design. However, I do believe since static fields/methods/accessors are available without any sort of guard they will likely be prohibited to use const _foo = await connect();
async class X {
static foo = _foo;
} I'm open to alternative opinions, but it seems the ability to form a complete class derived from async operations is simpler than an instance. The problems with instances largely come from encapsulation and inheritance that do not affect construction of the class itself. If reasonable semantics for |
@bmeck My idea about Promise Class that Class is sync, but with async constructor. With Async Class where all async - the first thing that came to mind:
All text in my msg - just thoughts... |
Great to see this proposal.
I tried to discuss the same ideas before, but go with syntax problems...
I have no feedback for my last idea, maybe can hear here some arguments:
Maybe then we can use some syntax like:
The text was updated successfully, but these errors were encountered: