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

On Tue, Jan 14, 2014 at 8:34 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

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?

~TJ

Received on Wednesday, 15 January 2014 21:27:13 UTC