-
Notifications
You must be signed in to change notification settings - Fork 17
Add a way to expose failing constructors #9
Comments
It's pretty strange, but it's actually possible to make a function (or proxy) such that const x = await new Y(); works, and even to make function Y() {
if (!new.target) {
return Promise.reject("Illegal invocation");
}
return new Promise(r => {
setTimeout(() => r(createActualY()), 1000);
});
} |
I guess my concern with my above suggestion is that so far for async construction we've instructed people to use factory methods (e.g. On the other hand these are pretty specialized objects, proxying from another thread, and not general web platform objects representing resources that need to be created async. So maybe it's OK for them to be special. |
I actually think making I’d totally be down with that. @bfgeek WDYT? |
Yeah I'm not sure... the argument against this in my head is that it's one thread bounce that we can easily remove, that 99.99% of the time isn't useful. I.e. a = await new api.A();
a.f1();
a.f2(); (two main->bg tasks). vs. a = new api.A();
a.f1();
a.f2(); (only one main->bg task). |
I.e. multiple calls which we don't |
Developers can still batch if desired, no? const [a1, a2, a3, a4] =
await Promise.all([
new api.A(),
new api.A(),
new api.A(),
new api.A(),
]); Another thing I realized: The more I think about it, the more I like the |
The polyfill now uses |
For completeness’ sake:
The polyfill does it in one bounce. I’m sure a native implementation can do the same ;) |
Make constructors asynchronous (fixes #9)
From WICG discussion: Post 1, Post 2
TL;DR:
try
/catch
and now they need to beThe text was updated successfully, but these errors were encountered: