I don't really understand why you're arguing that iterators should only be
used in one way. A developer should probably never take a generator
somebody else wrote and stick it into something like Q.async and expect it
to handle being re-entered at some later turn of the event loop correctly.
But I would expect most people to be explicitly stating when a function
generator is re-entrant at some undetermined future point in time by using
Q.async(function*(){}), or what have you. Q.async returns a separate
abstraction (a promise) that completely represents an asynchronous value.I guess I still haven't seen an example where a function generator would be used that you couldn't explicitly tell how it was being used, so I'm just a little lost as to what the issue is here. But I feel we've lost the original topic of this conversation. I agree Promises shouldn't be made a standard Node construct, but I see no reason not to use generators for asynchronous control flow. Andrew Gaspar On Mon, Aug 5, 2013 at 4:26 PM, Mikeal Rogers <[email protected]>wrote: > > On Aug 5, 2013, at 4:16PM, Jake Verbaten <[email protected]> wrote: > > 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. > > > This is *exactly* what I'm worried about. > > I'm trying to think about this not in the context of "all the code I > write" but "all the code i use, and what they use, and what they use". > > If yield becomes a successful pattern a library user won't be aware of all > the dependent generators it has, just like very few people are aware of > their dependencies dependencies dependencies. Yet somehow all of the actors > along this chain have to be sure they didn't use generators one way when I > want to use them another way. > > This is very concerning. Patterns should enforce or at the very least > visibly display the compatibility they offer so that actors can coordinate > without active collaboration, this sounds like it depends on a bunch of > people all agreeing about how their API should be used without any visible > indicator stating such. > > One of two things will happen: > > * Most iterators will be used for async which means that very few people > will write them in a way that i'm worry about > OR > * Most iterators won't be use for async which means mixing up the two > cases will end in bugs *only* visible at scale. > > -Mikeal > > -- > -- > 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.
