On Thu, Jan 27, 2011 at 8:00 AM, Irakli Gozalishvili <[email protected]>wrote:
> Hi, > > I was curious to know what is the state of the following proposal: > http://wiki.ecmascript.org/doku.php?id=strawman:concurrency It's on the agenda for the upcoming March meeting. I was planning to do some more work on it before declaring it ready for discussion. But since you raise it, I'm happy enough with it in its current state. I can clarify my remaining issues with it as discussion proceeds. So This page is now ready for discussion. I do expect that this strawman is too large to be accepted into ES-next as a whole. To get some of it accepted -- syntactic sugar + some supporting semantics -- we need to find a clean boundary between what kernel and extension mechanism the platform needs to provide vs the remaining functionality that should be provided by libraries using these extension mechanisms. For example, Tyler's web_send uses such an extension API in ref_send to stretch these operations onto the network, by mapping them onto JSON/RESTful HTTPS operations. Kris Kowal's qcomm library uses Q.makePromise (like that proposed above) to stretch these operations over WebSockets, whose connection-oriented semantics enables a better mapping at the price of more specialized usage. I hope that Kevin Reid's caja-captp can also be reformulated as a library extending the Q API. (See links to ref_send, web_send, qcomm, and caja-captp at the bottom of the strawman page.) > > > I do believe that having ES native promises could provide drastically > better alternative for writing async code in comparison to currently popular > nested callback style. Also even though there are few implementations of Q > API adoption is still low IMO that's due to non obvious and verbose syntax. > Syntactic sugar described in the proposal really makes a lot of difference. > Also I don't see proposal for `Q.when` syntax and would love to know what is > the a plan for that. > Given a lightweight closure syntax, I don't think Q.when actually needs any further syntactic sugar. For example, here's the asyncAnd example from Figure 18.1 of <http://erights.org/talks/thesis/> in JS with this strawman + destructuring + the lightweight closure syntax from HOBD (Harmony of Brendan's Dreams): #asyncAnd(answerPs) { let countDown = answerPs.length; if (countDown === 0) { return true; } const {promise, resolver} = Q.defer(); answerPs.forEach(#(answerP) { Q.when(answerP, #(answer) { if (answer) { if (--countDown === 0) { resolver(true); } } else { resolver(false); } }, #(ex) { resolver(Q.reject(ex)); }); }); return promise; } The original asyncAnd in Figure 18.1 is in E, whose syntax was designed without legacy burden to make such code pleasant. Nevertheless, I don't think the code above suffers much in comparison. Of course, if you have a suggestion of how a sugared Q.when can improve on this enough to be worth the cost of yet more sugar, please suggest it. Thanks. > > Thanks > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/ > Address: 29 Rue Saint-Georges, 75009 Paris, France<http://goo.gl/maps/3CHu> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
