W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

RE: [promises] resolver's resolved flag check on promise callback

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 28 Jun 2013 16:48:09 +0000
To: Yutaka Hirano <yhirano@chromium.org>, Anne van Kesteren <annevk@annevk.nl>
CC: "www-dom@w3c.org" <www-dom@w3c.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F8781DDD9@BY2PRD0510MB354.namprd05.prod.outlook.com>
It's important to distinguish between the fundamental three states, viz. fulfilled, rejected, and pending, as opposed to the two "fates" unresolved and resolved. The former impact the behavior of the promise, whereas the latter impact the relation between promise and resolver.

As such I don't think your proposed suggestions are the best way to go. But, I do agree the current spec is fairly confusing in this area and could be improved. I will try to make time for a pull request over the next week.
________________________________
From: Yutaka Hirano<mailto:yhirano@chromium.org>
Sent: 6/28/2013 9:41
To: Anne van Kesteren<mailto:annevk@annevk.nl>
Cc: www-dom@w3c.org<mailto:www-dom@w3c.org>
Subject: Re: [promises] resolver's resolved flag check on promise callback

> What do you mean by 4.4?
Sorry, I meant the entry in resolver's resolve algorithm.

  4. If calling the [[Call]] internal method threw an exception, catch it and run context object's reject with the thrown exception and the synchronous flag if set.

> I think you're right that this is problematic, but it's not entirely clear to me this solves it.
I think adding adhoc checks works, but doing the following will solve the problem more cleanly.
 - Remove resolved flag.
 - Add "resolving" state.
 - fulfill algorithm (not fulfill method) does nothing if the promise's state is not "pending" nor "resolving".
 - resolve algorithm (not resolve method) does nothing if the promise's state is not "pending".
 - reject algorithm (not reject method) does nothing if the promise's state is not "pending" nor "resolving".
 - resolve algorithm sets the promise's state as "resolving".

On Fri, Jun 28, 2013 at 10:53 PM, Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
On Thu, Jun 27, 2013 at 2:51 AM, Yutaka Hirano <yhirano@chromium.org<mailto:yhirano@chromium.org>> wrote:
> Hi, I am implementing promises and I have a question.
> In resolve algorithm, we create promise callbacks for the given resolver and
> pass them to a (possibly) user defined function.
> A user can call them more than once.
> Since a promise callback for |resolver| and |algorithm| runs |resolver|'s
> |algorithm| and the |algorithm| doesn't checks |resolver|'s resolved flag,
> it seems that the promise can be resolved or rejected multiple times.
> Is it correct? I think the check for the resolved flag is needed in:
>  - promise callback
>  - 4.4 in resolve algorithm.

What do you mean by 4.4? I think you're right that this is
problematic, but it's not entirely clear to me this solves it.


--
http://annevankesteren.nl/
Received on Friday, 28 June 2013 16:48:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:21 UTC