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

Naming #1

Open
Dimtime opened this issue Feb 12, 2020 · 6 comments
Open

Naming #1

Dimtime opened this issue Feb 12, 2020 · 6 comments

Comments

@Dimtime
Copy link

Dimtime commented Feb 12, 2020

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:

  • Async class - bad if only have async constructor
  • Async constructor - bad because our class must return object

Maybe then we can use some syntax like:

promise class Name{
constructor(){} // <= return promise obj
}
promise class extends Name{} // promise class| simple class
@bmeck
Copy link
Member

bmeck commented Feb 12, 2020

Can you clarify how this differs from async vs non-async functions? e.g. async functions return promises, but do not use the word promise

@Dimtime
Copy link
Author

Dimtime commented Feb 12, 2020

Can you clarify how this differs from async vs non-async functions? e.g. async functions return promises, but do not use the word promise

@bmeck This idea go from syntax dispute Async Class.
That some people dont like Async Class naming - because we dont have async class, but only async constructor.

My syntax just simple to avoid this argument. And we can do constructor - async default:

promise class Name{ // new syntax for separation and understanding
constructor(){} // <= async function by default 
}

@bmeck
Copy link
Member

bmeck commented Feb 13, 2020

@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();
}

@Dimtime
Copy link
Author

Dimtime commented Feb 13, 2020

might cover things outside the constructor

@bmeck for me Async Class is fine and support fields is good.
But what with Static then?

async class X {
static  foo = await connect();
}

When we must await them? Or dont support?

@bmeck
Copy link
Member

bmeck commented Feb 13, 2020

@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 await. Unlike instance properties, static properties wishing to ensure they are available and don't have an incomplete class can use await when creating the class itself.

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 await in classes is proposed it can be done as a follow on most likely.

@Dimtime
Copy link
Author

Dimtime commented Feb 13, 2020

I'm open to alternative opinions

@bmeck My idea about Promise Class that Class is sync, but with async constructor.
For me more easy have two proposal, but if one of them go to stage4 be good...

With Async Class where all async - the first thing that came to mind:
that we have promise of class, but it will be more code after...

async class Test {}; // <= just promise not class
//await Test(); // <= now init of class begin
async class ExtTest extends Test{ } 
await ExtTest(); //we can add lazy init for subclass 

All text in my msg - just thoughts...

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

2 participants