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

Promise/A+ (http://promises-aplus.github.io/promises-spec/#promise_states)
states that

  When in fulfilled, a promise:
    must not transition to any other state.

and it is easy to understand.
I don't understand what the corresponding statement is in DOM/promises:

  1. A promise must not transition to any other state when it is in
fulfilled state.
  2. A promise must not transition to any other state when its resolver's
resolved flag is set.
  3. A promise must not transition to any other state when it is in
fulfilled state and its resolver's resolved flag is set.
  4. A promise must not transition to any other state when it is in
fulfilled state or its resolver's resolved flag is set.

I think that is 1, right?
If so, can we have the state check in fulfill / reject algorithms?



On Sat, Jun 29, 2013 at 1:48 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

>  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 <yhirano@chromium.org>
> Sent: 6/28/2013 9:41
> To: Anne van Kesteren <annevk@annevk.nl>
> Cc: 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>wrote:
>
>> On Thu, Jun 27, 2013 at 2:51 AM, Yutaka Hirano <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/
>>
>
>