Originally this came up while studying these slides on async generators: https://docs.google.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU/edit
In this design, `Observable.observe` is specified as taking a generator which acts as a data sink. However, because of the "lost next" issue, it appears that newborn generators must be "pumped" before they can be used by that function. In the following gist, I've implemented `readFile` and `writeFile` using async generators. The async/await stuff isn't crucial to the point. I've implemented the functions using both `x = yield y` and a purely hypothetical `next` keyword to pull data from the consumer. https://gist.github.com/zenparsing/26b200543bb8ae0ca4df (BTW, I'm not asking for any changes - this is just a theoretical question.) On Tue, Aug 19, 2014 at 9:21 AM, Kevin Smith <zenpars...@gmail.com> wrote: > >> // the same, advancing to the first `yield` at instantiation >> class echo2 extends echo { >> construct(...args) { >> let iter = super(...args) >> iter.next() >> return iter >> } >> } >> > > Nice pattern! Would this also work? > > var skipFirst = genFn => function*(...args) { > var iter = genFn(...args); > iter.next(); > yield * iter; > }; > > var echo2 = skipFirst(echo); > > If we have decorators, then we can write: > > @skipFirst > function echo() { /*_*/ } > > which is fairly pleasant. > > Still, it seems like we're papering over a hole. In principle, why > shouldn't we be able to access the first next argument? > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
