[replying to a message you sent off-list, hope it is ok. /be]
Brendan Eich wrote:
Bradley Meck wrote:
Perhaps, but I am still a bit concerned functionality wise that I do
not have a clean way to force the `new generator()` piece of code to
be inside of the generator.
I think you've gone
Perhaps, but I am still a bit concerned functionality wise that I do not
have a clean way to force the `new generator()` piece of code to be inside
of the generator.
I cannot easily convert it akin to how new can be caught:
```
function* generatorFn() {
if (this instanceof generatorFn) {
Bradley Meck wrote:
Perhaps, but I am still a bit concerned functionality wise that I do
not have a clean way to force the `new generator()` piece of code to
be inside of the generator.
I think you've gone down a bad path. Even without task.js, couldn't you
put the promises .then'ing in the
Is that true even though then should fire after the generator unwinds its
stack? I am using regenerator right now while playing with this stuff.
On Jan 23, 2014 5:43 PM, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
arguments.callee.caller would have done that /trolling
Bradley Meck wrote:
Is that true even though then should fire after the generator unwinds
its stack?
True if .then always runs in a later turn -- sorry.
Still, my point stands: you are not using task.js-like
scheduler/combinator approach for an apples-to-apples comparison with
await. If you
Still, my point stands: you are not using task.js-like
scheduler/combinator approach for an apples-to-apples comparison with
await. If you do, then we're down to the obligation of a task.js download,
and some syntactic sugar.
see comments in gist, adding a library also has some stuff with
6 matches
Mail list logo
