W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 14 Jan 2014 11:34:09 -0500
Message-ID: <52D56701.4020309@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>, Takeshi Yoshino <tyoshino@google.com>, "www-tag@w3.org" <www-tag@w3.org>
CC: public-webapps <public-webapps@w3.org>
On 1/14/14 10:44 AM, Domenic Denicola wrote:
> So maybe we need slightly better phrasing; help appreciated.

Maybe the right way to spec this is to simply use two algorithms... 
Algorithm A has some steps, then says to perform B asynchronously and 
returns a promise.  B has a bunch of steps that end with resolving the 
promise.  That avoids the issue of having steps-after-return and also 
avoids the issue of the steps of B needing to be indented a level and 
not clearly separated from the (conceptually separate) steps of A.

I think the only issue with the two-algorithm setup might be 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigating-across-documents 
in which there is actually a goto from what I call B above (in 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-redirect-step 
) to a step that is in A 
(http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step 
).  I can't say that I'm terribly happy with that setup, though, so I 
think discouraging it in general is _not_ a bad thing.

This seems like too much overhead when B is only a step or two, of 
course, maybe in those cases inlining it inside a "do these steps async" 
block is good.

-Boris
Received on Tuesday, 14 January 2014 16:34:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:08 UTC