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

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

From: Takeshi Yoshino <tyoshino@google.com>
Date: Wed, 15 Jan 2014 14:23:31 +0900
Message-ID: <CAH9hSJYX9Wvav+3K1za0rXPFZULLoXL4=xrT7fg5boJXmJEVJQ@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>, public-webapps <public-webapps@w3.org>
To address, jgraham's point, let's go back to just use "Run ..." style
phrasing.

I agree that we shouldn't mislead readers that task queuing is always
necessary. Moreover, I think algorithm may be allowed to be done either
synchronously or asynchronously for some cases. Maybe we could add
"possibly" to mean it's not forced to be run later for such a case?

How about introducing some markups such as "[Async]" and a note of detailed
explanation (no need to queue a task, etc.)? Readers are guided to read the
note to understand what they mean, and actually more likely to do so
compared to just writing "do X asynchronously". I imagine. Not sure.

1. sync_work_A.
2. sync_work_B.
3. Let p be a newly-created promise.
4. [PossiblyAsync] possibly_async_work_S.
5. [PossiblyAsync] possibly_async_work_T.
6. [Async] async_work_X.
7. [Async] async_work_Y.
8. Return p.

Right after returned from this method, we observe side effect of sync_work
and may observe possibly_async_work's but not async_work's.

If too noisy, modularize as Boris said (
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0066.html).
Received on Wednesday, 15 January 2014 05:24:19 UTC

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