W3C home > Mailing lists > Public > www-tag@w3.org > January 2014

Re: [promises] Guidance on the usage of promises for API developers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 16 Jan 2014 19:42:27 +0100
Message-ID: <CADnb78hi4k3ardj79wLVHXyzNKzXssFfkf0xuyFnKwijf7RByQ@mail.gmail.com>
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.

Received on Thursday, 16 January 2014 18:42:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:24 UTC