> Similar problems have crept in to node libraries that called asynchronous
iterators "forEach" and their consumers assumed that this blocked the VM
since Array.forEach blocks the VM until completion.
There are two distinct usage patterns around generators, one that enhances
underscore and one that enhances async.
If you were to combine generators with underscore you would be able to do
things like
```js
for (let v of _(thing).map(mapper).filter(filterer)) {
// do stuff
}
```
This is a safe usage of a generator as it's not async nor stateful.
If you enhance async with generators you would be able to do things like
```js
var task = async(function* () {
var result = yield async.map.bind(null, list, mapper)
// do stuff
})
```
Here you would know that anything can happen between calling async.map and
you having access to the result because yield is used in an asynchronous
manner.
The only confusion is knowing whether your using generators for async flow
control or whether your using them to generate iterators you iterate over.
Once you learn to only use the first type in synchronous fashion and only
use the second type in an asynchronous fashion the confusion goes away.
On Mon, Aug 5, 2013 at 2:40 PM, Mikeal Rogers <[email protected]>wrote:
> I don't think you understand what I'm saying, I'll try to be clearer.
>
> Callbacks that use node's standard callback interface are resolved exactly
> once. From the point at which they begin to when they end the author can
> assume that any code they are running is the *only* code running in the VM
> and that state will only mutate between other callbacks passed to other
> APIs before resolving the callback they were given. In other words, state
> mutation boundaries are visible, explicit and consistent.
>
> Generators iterate over data in an iterable manor but because they cannot
> yield between turns of the event loop their condition is assumed to be
> resolved in one stack. For instance, if I offer you a generator my
> assumption is that if you present an API to another consumer that consumer
> will *also* call yield on your API to consume it iterably or consumer the
> entire generator until completion.
>
> While it is certainly *possible* that someone might decide not to offer a
> yield API and instead to turn the event loop before I'm finished and keep
> the generator yielded between cycles, I would bet that most people assume
> it won't happen and won't make attempts to be safe between concurrent
> iterations of the same generator.
>
> My concern is not that generators are "magical" but that the current
> implementation *appears* to offer assurances that *we* will go out and
> break.
>
> Similar problems have crept in to node libraries that called asynchronous
> iterators "forEach" and their consumers assumed that this blocked the VM
> since Array.forEach blocks the VM until completion.
>
> If 95% of the time generator authors don't have to worry about maintaining
> safety between concurrent iterations of the same generator history shows
> that a good number of them never will and will just break at scale in
> really fun (horrendous) to debug ways.
>
> -Mikeal
>
> On Aug 5, 2013, at 2:18PM, Christopher Probst <
> [email protected]> wrote:
>
> The generators are not magical. They do basically the same as callbacks
> but they invert the inversion of control optically.
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
