On 15 March 2013 02:33, Jason Orendorff <jason.orendo...@gmail.com> wrote: > On Thu, Mar 14, 2013 at 3:48 PM, Andreas Rossberg <rossb...@google.com> > wrote: >> >> On 8 March 2013 18:23, Jason Orendorff <jason.orendo...@gmail.com> wrote: >> > and you definitely don't want new state here, because what would that >> > even >> > mean? A read position is kind of inherent to a file descriptor, right? >> >> A generator is an abstraction that is intended to be invokable many >> times. Are you saying that there are generators for which you cannot >> do that? > > Eh? No, I'm saying you generally don't want to restart functions > automatically and implicitly.
Hm, where do you see "automatically and implicitly"? The whole point of the proposal is to be more *explicit* about when a fresh iterator is created, and who expects whom to do that. > Also—if you wanted to use generators in a really coroutine-like way, like > task.js does, under your scheme you'd have to explicitly call the @iterator > method in order to get the object you want, the one that has .next(), > .send(), .throw(), and so on. (Not a showstopper, as it's going to be pretty > specialized code that does that.) Yes, but that would also occur inside the task.js abstractions, wouldn't it? /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
