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

On Thu, Jan 16, 2014 at 10:42 AM, Anne van Kesteren <> wrote:
> On Wed, Jan 15, 2014 at 10:26 PM, Tab Atkins Jr. <> 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.

I mean, if you're trying to do a straight-forward translation, you'd
want a nested "do these steps async" step before the return, which
would map to a setTimeout() of those steps or whatever.  But that's
clumsier to read and write clearly.  It's pretty trivial to take the
"do this sync, do the rest async" and translate it into JS in exactly
that way.

> 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.

This is also very easy to express in algorithms if you do it
independently from the straight-line algorithm for the function, and
is similarly easy to translate into adding a listener before the
return in the real code.

I like optimizing for spec authors here, because it makes it more
likely that the spec will be written correctly.  Optimizing for
triviality of conversion to JS seems like a less important thing,
particularly since the translation is *still* pretty trivial.


Received on Thursday, 16 January 2014 22:15:16 UTC