- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 16 Jan 2014 19:42:27 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <domenic@domenicdenicola.com>, Takeshi Yoshino <tyoshino@google.com>, "www-tag@w3.org" <www-tag@w3.org>, public-webapps <public-webapps@w3.org>
On Wed, Jan 15, 2014 at 10:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > As a voice of dissent, I *really like* the "return P, and complete the > rest of these steps asynchronously" pattern. It's just your > "algorithm A and B" pattern, but put in a single list. Having the > sync section entirely before the async section works well for avoiding > any issues with the spec author accidentally trying to do some sync > operation in the middle of it. You still get the benefit of > straight-line algorithms, though, which is nice. > > Is the concern just that it's slightly harder to read for non-implementors? I think the concern is that it does not map to JavaScript. What you need for many asynchronous patterns if you want them to map to JavaScript is to set up some kind of listener (e.g. for network data) before you return and then run code once that listener runs (which could resolve a promise). Potentially you might need to queue a task from that listener, depending on where it would run. -- http://annevankesteren.nl/
Received on Thursday, 16 January 2014 18:42:54 UTC