Maybe, but i think it question similiar to "factory vs class":
we can use Сlass now, but why not to extend it to Async then?

"Also, note that you can return promises out of the constructor (and I've
done it before)"

Like callback? Maybe, but again it simillial to "await vs callback" then.

I just like Class,Async and Await patterns.
And think:this some sugar can be useful for some people like me...

"Is an async factory function/method not sufficient to do this?"
Maybe, but i think it question similiar to "factory vs class":
we can use Сlass now, but why not to extend it to Async then?
"Also, note that you can return promises out of the constructor (and I've
done it before)"
Like callback? Maybe, but again it simillial to "await vs callback" then.
I just like Class,Async and Await patterns.
And think:this some sugar can be useful for some people like me...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180216/b04b9877/attachment.html>

"Also, note that you can return promises out of the constructor (and I've

done it before)"

Like callback?

I think he means literally returning a promise. If you return an object out
of the constructor, that becomes the result of the new operation. So you
can literally return a promise of an instance instead of an instance
(fiddle):

"It gets ugly(ier) when you want to extend that. :-) "
Ok, i get it, but yes i prefer some more sugar like as i suggested before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180216/c9d52903/attachment.html>

You can just call an async method from the constructor (without await) -
and then let that async method handle all the asynchronicity.

Does this satisfy your use case?

I think async constructor would make more sense than async class.
Calling new MyObjectAsync() would have to return a promise for the
object, requiring await to actually get the object.

My only reservation is that it does require caution not to presume that
new X() isn't actually an instance of X (but that await new X() is).
Otherwise I don't mind it.

You can just call an async method from the constructor (without await) -
and then let that async method handle all the asynchronicity.
Does this satisfy your use case?
I think `async constructor` would make more sense than `async class`.
Calling `new MyObjectAsync()` would have to return a promise for the
object, requiring `await` to actually get the object.
My only reservation is that it does require caution not to presume that
`new X()` isn't actually an instance of `X` (but that `await new X()` is).
Otherwise I don't mind it.
On Fri, 16 Feb 2018 at 14:14 Dimitrian Nine <dimtimeforever at gmail.com>
wrote:
> "It gets ugly(ier) when you want to extend that. :-) "
>
> Ok, i get it, but yes i prefer some more sugar like as i suggested before.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180217/84436661/attachment.html>

"You can just call an async method from the constructor (without await) -
and then let that async method handle all the asynchronicity."

Not sure about it - how control? callback?
I prefer async/await then.

"I think async constructor would make more sense than async class"

Maybe: i use it for class more for difference between class and async class
was more visible.
But yes in total idea about async constructor.
Both variants work for me.
What more useful - i dont sure...

"You can just call an async method from the constructor (without await) -
and then let that async method handle all the asynchronicity."
Not sure about it - how control? callback?
I prefer async/await then.
"I think async constructor would make more sense than async class"
Maybe: i use it for class more for difference between class and async class
was more visible.
But yes in total idea about async constructor.
Both variants work for me.
What more useful - i dont sure...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180217/bd47ad94/attachment.html>

Of course if you wanted to await at the constructor call level (and await
inside the constructor itself), e.g.

const myObject = awaitnew MyObject();

...then of course you would need the "async constructor" feature, like
you've requested, but then new MyObject() would return a promise.

Personally I have no problem with this:

It suffers from the same bug-set than you would get if you converted a
synchronous function to an asynchronous one (i.e. the need to await).

Like this:
```js
class MyObject{
constructor(){
initializeAsync();
}
async initializeAsync(){
await doSomething();
await doSomethingElse();
//etc.
}
}
```
Of course if you wanted to await at the constructor call level (and await
inside the constructor itself), e.g.
```js
const myObject = await new MyObject();
```
...then of course you would need the "async constructor" feature, like
you've requested, but then `new MyObject()` would return a promise.
Personally I have no problem with this:
It suffers from the same bug-set than you would get if you converted a
synchronous function to an asynchronous one (i.e. the need to await).
On Sat, 17 Feb 2018 at 11:13 Dimitrian Nine <dimtimeforever at gmail.com>
wrote:
> "You can just call an async method from the constructor (without await) -
> and then let that async method handle all the asynchronicity."
>
> Not sure about it - how control? callback?
> I prefer async/await then.
>
> "I think async constructor would make more sense than async class"
>
> Maybe: i use it for class more for difference between class and async
> class was more visible.
> But yes in total idea about async constructor.
> Both variants work for me.
> What more useful - i dont sure...
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180218/ba7e4928/attachment-0001.html>

"new MyObject() would return a promise "
I have one idea about it, but not sure good or not...
async class and then newAsync
Maybe this way more good for someone...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180218/49f4d612/attachment.html>

I never said there was. I said you must handle rejection, or propagate the
promise. Or, yes, you can ensure that the promise is never rejected, but
that's not what the code I was responding to did. It left the door wide
open to unhandled rejections.

-- T.J. Crowder

On Sun, Feb 18, 2018 at 9:07 AM, Naveen Chawla <naveen.chwl at gmail.com>
wrote:
>
> There is no rule that says you must propagate every promise.
I never said there was. I said you must handle rejection, or propagate the
promise. Or, yes, you can ensure that the promise is never rejected, but
that's not what the code I was responding to did. It left the door wide
open to unhandled rejections.
-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180218/37930c5e/attachment.html>

Having the constructor return a Promise is generally considered bad
practice, since it breaks new X instanceof X, which in general breaks
inheritance.

So, for this idea to work, you really shouldn't mark constructor as async
(since this might suggest it returning a Promise, which it mustn't);
instead, you would have to make the constructor return this, then make the
asynchronous initialization, and then execute the rest. In other words,

The next problem with this idea is that you can't statically decide what new something is about to construct. Since something might be an async class,
the StatementList following the construction of something would always have
to be wrapped in a callback.

Long story short, introducing this feature would slow down new/
Reflect.construct.

"Long story short, introducing this feature would slow down new/
Reflect.construct"
"since this might suggest it returning a Promise, which it mustn't "

Can it help: if async class constructor will be return Promise(obj) and i
suggest before use newAsync for that practice?

Slow... but how much?

"Long story short, introducing this feature would slow down new/
Reflect.construct"
"since this might suggest it returning a Promise, which it mustn't "
Can it help: if async class constructor will be return Promise(obj) and i
suggest before use newAsync for that practice?
Slow... but how much?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180218/3b8e7f80/attachment.html>

I think awaitNew MyObject() would fit the thrust of your idea more. This
would allow new MyObject() to still be an instance of the object instead
of a promise, even if the constructor is async. It would dispatch the async
parts of the constructor to the background instead of awaiting it. e.g.:

However, I have no problem the 1st version (new MyObject() returning a
promise if the constructor is async). I think it's more consistent with how
functions work anyway. But awaitNew serves the same requirement while
ensuring new MyObject() is always an instance of MyObject.

I think `awaitNew MyObject()` would fit the thrust of your idea more. This
would allow `new MyObject()` to still be an instance of the object instead
of a promise, even if the constructor is async. It would dispatch the async
parts of the constructor to the background instead of awaiting it. e.g.:
```js
class MyObject {
async constructor(){
//sync stuff
await doAsyncStuff();
//etc.
}
}
const
myObjectWithOnlySyncStuffCompleted = new MyObject(), //Gets a new
instance but with only the "sync stuff" completed. Async stuff gets
dispatched to the background
myObjectWithAsyncStuffCompleted = awaitNew MyObject() //Gets a new
instance with everything (including async stuff) completed
;
```
However, I have no problem the 1st version (new MyObject() returning a
promise if the constructor is async). I think it's more consistent with how
functions work anyway. But `awaitNew` serves the same requirement while
ensuring `new MyObject()` is always an instance of `MyObject`.
On Sun, 18 Feb 2018 at 17:16 Dimitrian Nine <dimtimeforever at gmail.com>
wrote:
> "Long story short, introducing this feature would slow down new/
> Reflect.construct"
> "since this might suggest it returning a Promise, which it mustn't "
>
> Can it help: if async class constructor will be return Promise(obj) and i
> suggest before use newAsync for that practice?
>
> Slow... but how much?
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180218/73fc357b/attachment.html>

I'm still struggling through this thread to see why a static factory
method/function with a private constructor/class doesn't suffice for
this, or in this case, just procedural functions? (That's what I
normally do, even in ES5.)

I answered earlier:
<<Maybe, but i think it question similiar to "factory vs class">>

Yes, you can, but for me more easy to work with classes.
And i just want to extend the functionality for work with async - that all.

"why a static factory"
I answered earlier:
<<Maybe, but i think it question similiar to "factory vs class">>
Yes, you can, but for me more easy to work with classes.
And i just want to extend the functionality for work with async - that all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180219/30f87247/attachment.html>

I just thought I'd politely point out here that JS isn't a purely OO
language (it's even less so class-based OO - ES classes are about 90%
sugar over prototype-based inheritance*). Also, C#, the language that
first had this kind of syntax, also doesn't have this.
Constructors should be seen as what allocates and instantiates the
instance, not what loads and creates the instance, and nearly every
OO language out there assumes the former model, that of
allocation/instantiation. (C++ is one of the unusual ones that
conflates the two with its RAII.)

* There's a few features ES classes offer that prototypes don't, with
new.target being the biggest one. But in general, ES classes aren't
like traditional classes - they can be easily modified, up to and
including their inheritance chain (which is downright trivial). Also,
duck typing is reified in the spec, with that being used instead of
interfaces when subclassing. Contrast this with Python, which makes it
very difficult to change inheritance chains at runtime, and Ruby,
which has had bugs over invalid assumptions with this (Classes
don't invalidate their method caches with initialize_copy).

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com

I just thought I'd politely point out here that JS isn't a purely OO
language (it's even less so class-based OO - ES classes are about 90%
sugar over prototype-based inheritance\*). Also, C#, the language that
*first* had this kind of syntax, [also doesn't have this][1].
Constructors should be seen as *what allocates and instantiates the
instance*, not *what loads and creates the instance*, and nearly every
OO language out there assumes the former model, that of
allocation/instantiation. (C++ is one of the unusual ones that
conflates the two with its RAII.)
\* There's a few features ES classes offer that prototypes don't, with
`new.target` being the biggest one. But in general, ES classes aren't
like traditional classes - they can be easily modified, up to and
including their inheritance chain (which is downright trivial). Also,
duck typing is reified in the spec, with that being used instead of
interfaces when subclassing. Contrast this with Python, which makes it
very difficult to change inheritance chains at runtime, and Ruby,
[which has had bugs over invalid assumptions with this][2] (Classes
don't invalidate their method caches with `initialize_copy`).
[1]: https://stackoverflow.com/questions/8145479/can-constructors-be-async
[2]: https://github.com/charliesome/charlie.bz/blob/master/posts/changing-the-superclass-of-a-class-in-ruby.md
-----
Isiah Meadows
me at isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
On Mon, Feb 19, 2018 at 12:41 PM, Dimitrian Nine
<dimtimeforever at gmail.com> wrote:
> "why a static factory"
>
> I answered earlier:
> <<Maybe, but i think it question similiar to "factory vs class">>
>
> Yes, you can, but for me more easy to work with classes.
> And i just want to extend the functionality for work with async - that all.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

"ES classes are about 90% sugar"
"ES classes aren't like traditional classes"
Yes and i just want to more sugar for them - just simple.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180219/4f9dcb23/attachment-0001.html>

"why a static factory"
And more notes:
"return img" - this is cut version
In my example you get obj - not image.
And my sample was simple.
I hope not so long left to class private var + decorators
And sample can be then more complex with it:
async class Class{
@some_decorator
static private method(){}
static var = some_var
}
and have not onle one Extends
Class
ExtClass
ExtExtClass
Maybe i try to force events, but time never waits...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180222/8ec1d6fa/attachment.html>

«Classes, introduced in ECMAScript 2015, are primarily
syntactical sugar over JavaScript's existing prototype-based inheritance.
The class syntax does not introduce a new object-oriented inheritance model
to JavaScript»
«Classes are in fact "special functions"»