forbes at lindesay.co.uk (2017-01-08T05:35:32.736Z)
Certainly not optimal, though, and I'd rather it *not* become the
primary idiom - it lacks the intent of a Python-like `with` statement.
Also, `next`/`return` doesn't exactly mirror `__enter__`/`__exit__`
from Python. What really happens with `for ... of` is closer to
`next`/`next`, where the first call reports `{done: false, value:
whatever}`, and the second `{done: true}`. It's more of a unusual pun
than anything, a theoretical equivalence providing an unintuitive
workaround.
I would welcome a strict-mode-only modification to `with` that allows
something like that, and adding `with await` for Promise-resolving
equivalents.
Certainly not optimal, though, and I'd rather it *not* become the primary idiom - it lacks the intent of a Python-like `with` statement. Also, `next`/`return` doesn't exactly mirror `__enter__`/`__exit__` from Python. What really happens with `for ... of` is closer to `next`/`next`, where the first call reports `{done: false, value: whatever}`, and the second `{done: true}`. It's more of a unusual pun than anything, a theoretical equivalence providing an unintuitive workaround. I would welcome a strict-mode-only modification to `with` that allows something like that, and adding `with await` for Promise-resolving equivalents. ----- Isiah Meadows me at isiahmeadows.com On Thu, Dec 29, 2016 at 11:05 PM, Jamesernator <thejamesernator at gmail.com> wrote: > 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 fd of open("/path/to/file", {mode: "r+"})) { > const bit = fs.readSync(fd) > ... > } > ``` > > I can definitely imagine a Python-esque `with` statement though (perhaps > with `Symbol.open/Symbol.close`) then you just use something like Python's > contextlib (https://docs.python.org/3.7/library/contextlib.html) utility > functions for converting generator based resources to > `Symbol.open/Symbol.close`. > > For now though the `for` loop approach is a relatively good workaround (as > `next/return` effectively emulate Python's `__enter__/__exit__`). > > > > On 30/12/16 04:17, Isiah Meadows wrote: >> >> 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 >> without the use of exceptions. >> ----- >> >> Isiah Meadows >> me at isiahmeadows.com >> >> >> On Thu, Dec 29, 2016 at 9:05 AM, Raul-Sebastian Mihăilă >> <raul.mihaila at gmail.com> wrote: >>> >>> 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 <ljharb at gmail.com> >>> wrote: >>>> >>>> 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). >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > >