On Thu, Mar 14, 2013 at 3:48 PM, Andreas Rossberg <[email protected]>wrote:
> On 8 March 2013 18:23, Jason Orendorff <[email protected]> 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. Currently, if you call a generator, you get a coroutine. I think what you're suggesting would instead make generators return a coroutine factory, and have coroutines implicitly created in many situations. That seems like it might be bad to me. Not all generators are as straightforward as enum. They can have side effects, etc. Implicitly creating extra copies of these things which are kind of like new threads of execution sounds potentially awful to me. 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.) I can see that the suggestion might look like a complication, but I > think it is a fairly minor one, and more importantly, in practice will > almost always be confined to abstractions. > I agree that in most use cases, no difference will be observed. -j
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
