00 PM, Michał Wadas
> wrote:
> >
> > After I started writing code extensively using async-await I have
> noticed that I would like to have automated way of dealing with resource
> management.
>
> This is something I'd really like to see as well.
>
> What&
On Fri, Nov 10, 2017 at 3:00 PM, Michał Wadas wrote:
>
> After I started writing code extensively using async-await I have
noticed that I would like to have automated way of dealing with resource
management.
This is something I'd really like to see as well.
What's the motivati
After I started writing code extensively using async-await I have noticed
that I would like to have automated way of dealing with resource management.
Scope-level manage was proven (Python, C++, Java at least) to be intuitive
and error proof.
Previous discussion on this topic: https://esdiscuss
Promise.using solves all that - give it a spin :)
On Tue, Jan 10, 2017 at 2:23 AM, Isiah Meadows
wrote:
> I'll note that the disposer pattern is a lot like Ruby's resource
> management idioms as well (probably closer). The biggest issue I've seen
> with it so far i
I'll note that the disposer pattern is a lot like Ruby's resource
management idioms as well (probably closer). The biggest issue I've seen
with it so far is only how hard it is to compose while still avoiding
leaks. Using one resource like that is easy, but joining multiple resour
Oh, Bluebird's `Promise.using` does that with very high certainly. The
reason we introduced `using` rather than let people just use the disposer
pattern is because it is very tricky to get right in userland - so the
library provided it.
On Fri, Jan 6, 2017 at 2:51 AM, Isiah Meadows
wrote:
> It'd
It'd be nice to have something like that reified into the language
somehow. I'll note that Bluebird's gotcha with `Promise.using`
multiple resources simultaneously is a huge issue, though, and it
should be avoided for anything standardized. (If one of them fail, the
rest should be closed either imm
And, on a similar note - a pattern has emerged in userland libraries all
over:
http://stackoverflow.com/questions/28915677/what-is-the-promise-disposer-pattern
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Hey,
We've actually worked on this extensively in bluebird with
http://bluebirdjs.com/docs/api/promise.using.html and disposers which give
something similar to the `with` syntax you describe.
There has also been work on a `defer` like abstraction. The tricky parts
were mostly getting it to work w
> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Isiah
> Meadows
> Sent: Saturday, December 31, 2016 8:34 AM
> To: J Decker
> Cc: Raul-Sebastian Mihăilă ; es-discuss disc...@mozilla.org>
> Subject: Re: Resource managem
Not enough. Not looking for an `await` replacement, but something
closer to Python's `with` statement or Java's `try`-with-resources.
Or, if you want something
Python: http://preshing.com/20110920/the-python-with-statement-by-example/
Java:
https://docs.oracle.com/javase/tutorial/essential/except
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
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
Such a protocol would make sense only if new specific syntax was added to
the language. But is that really necessary when this can be implemented
very easily without new syntax?
```js
async function open(file, opts, func) {
const fd = await fsp.open(file, opts);
await func(fd);
await fsp.cl
In [this GH issue in the async iteration proposal][1], I found that
the async iteration concept itself could theoretically be used for
resource management, such as in this example (copy/pasted from my
initial issue):
```js
const fsp = require("fs-promise")
async function *open(
19 matches
Mail list logo
