On Sep 4, 2011, at 11:06 AM, John J Barton wrote:

> As a reader I have to parse the function carefully to look for the 'yield'. 
> If I find one, then I know that this is not actually a function after all. 
> Then I need to mentally draw a line after the yield and label it "entry-point 
> #2".

This is addressed in ES6 by changing the head of the generator function as 
follows:

spawn(function* () {
    try {
        var [foo, bar] = yield join(read("foo.json"),
                                    read("bar.json")).timeout(1000);
        render(foo);
        render(bar);
    } catch (e) {
        console.log("read failed: " + e);
    }
});


> Next I have to read through the source of spawn() and track the lifetime-of 
> and references-to the object it received, seeking calls to send().

No, you can use spawn as a black box. It's an API entry point to the taskjs 
library. You do not need to read the source to use an API.


> Assuming I am understanding the idea, then my description above is also my 
> criticism: control and data flow is jumping around in unusual ways and 
> functions morph into multi-entry point things with new API.

There's no free lunch. Either we renounce adding new syntax by which to capture 
a shallow continuation, which leaves us with the nested callback function world 
of today, which people object to on several grounds:

* Nesting makes hard-to-read, rightward-drifting function spaghetti.

* Nesting increases the risk of capturing too much environment, potentially 
entraining memory for a long time -- bloat and leak bugs.

These are not unmanageable according to some JS hackers, but they are not 
trivial problems either. They keep coming up, in the Node community and among 
browser JS developers. They're real.


> On the positive side I can now see the advantage of this approach.  The I/O 
> request and action on its response are now neatly separated from the 
> spaghetti. I can study and curse at the yield/next/send code, but once I have 
> made that investment the source and sink of foo and bar are clearly related. 
> The funky stuff is in infrastructure not (mostly) in application code.

Right.

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to