Just a shot; but something ilke deasync ?
https://www.npmjs.com/package/deasync
it's not so much about ordering wait in the current code, but the current
code within outer code that's the issue somehow?
___
es-discuss mailing list
es-discuss@mozilla.org
The `for` loop approach works for synchronous resources as well
actually, there's nothing special about those `await`ed things e.g.
```js
const fs = require('fs')
function* open(file, opts) {
const fd = fs.openSync(file, opts)
try { yield fd } finally { fs.closeSync(fd) }
}
for (const
But keep in mind it still doesn't cover two key issues:
1. Synchronous resources do in fact exist (primarily in Node). You
need both for it to be effective.
2. Your suggestion isn't composable at all (like nearly every other
callback-driven API), and it prevents returning from inside the block
wit
I agree, but note that a resolved promise is not the same as a fulfilled
promise (https://tc39.github.io/ecma262/#sec-promise-objects).
On Thu, Dec 29, 2016 at 11:40 AM, Jordan Harband wrote:
> You'd need to wrap the body of your `open` function in a try/finally, and
> do the `fsp.close` in the
You'd need to wrap the body of your `open` function in a try/finally, and
do the `fsp.close` in the `finally` block - but otherwise that would
certainly work, provided that the promise returned from `func` did actually
settle (resolve or reject).
Assuming `fsp.open()` will always settle, but not a
5 matches
Mail list logo
