I had a similar thought a while ago for adapting non-promise functions, by
way of `async.resolve()` and `async.reject()`:
```javascript
async function asyncFunction() {
someAsync('data', (err, data) => {
if (err) async.reject(err);
async.resolve(data);
})
}
```
This differs from your proposal in that it's more explicit. Neither really
give much benefit beyond saving a few bytes of code, probably not worth the
extra complexity. It might be ok as an API, e.g. Promise.adapt(someAsync),
but the downside there is that it can't be very generic (an argument could
be made for the very common Node callback pattern where the last argument
to the function is the callback and the params are always err, result).
There are also existing NPM libraries to "promisify" module exports.
On Mon, 27 Feb 2017 at 08:42 Isiah Meadows <isiahmead...@gmail.com> wrote:
> May I add one more thing: the main topic this was about is adapting
> non-standard async APIs (like Node's error-first callback idiom) to the
> land of promises. Async functions and iterators are incredibly useful when
> you're dealing with just promises, especially consuming them, but this is
> about creating promise adapters, not consuming promises.
>
> On Sun, Feb 26, 2017, 18:52 Mark <m...@heyimmark.com> wrote:
>
> Codefined, just out of curiousity, do you have anything to do with this
> proposal that got announced today
> <https://github.com/tc39/proposals/pull/41>? Or is it just a coincidence?
> :)
>
>
> On Sun, Feb 26, 2017 at 3:07 PM Dean Tribble <trib...@e-dean.com> wrote:
>
> Should `callee()` be asynchronous here? To my mind, no, it shouldn't.
> Every single line here is synchronous, so the function itself should surely
> be synchronous. Shouldn't functions that may not have `await` in them, but
> instead that are actually asynchronous and hence use the `async return`
> keyword be the ones we define with `async`?
>
>
> In the Javascript (and Midori) model, concurrent execution of multiple
> activities is achieved by breaking those activities up into coarse-grained,
> application-defined "turns" (or "jobs") and interleaving those. An async
> boundary is where the current turn could end, and the turns for other
> concurrent activities might run, changing the state before the current
> activity proceeds.
>
> Therefore, callee must be async, because that declares that there could
> be a turn boundary within it, and thus, the rest of the state of the
> program could change as a result of the call. The caller of callee *must
> *ensure that it's invariants are correct before allowing other code to
> interleave with it.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
