W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

Re: [Promises] Out-of-sequence method invocation behavior

From: Rich Tibbett <richt@opera.com>
Date: Mon, 29 Jul 2013 13:15:38 +1000
Message-ID: <CAAsrAZAD7njLNEQeK2aGOhAxh5cJYSQ8CW4O7qwTiWpdcSQ-eA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
On Mon, Jul 29, 2013 at 12:07 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Sun, Jul 28, 2013 at 6:46 PM, Rich Tibbett <richt@opera.com> wrote:
> > In the XMLHttpRequest spec the state machine is used to define the
> expected
> > behavior when XHR object methods are called out of sequence. For
> example, if
> > I invoke send() when an XHR object is not in the |opened| state then
> > implementations are expected to throw an InvalidStateError exception [1].
> >
> > What is the expected behavior of Promises wrt out of sequence method
> > invocation? Specifically, if I call myPromise.then(func) after the
> Promise
> > has already reached the |fulfilled| state what should the UA do? Throw an
> > InvalidStateError (ala XHR), invoke the relevant fulfill or error
> callback
> > based on the object's previously established resolution or some other
> > behavior?
>
> This question suggests you may not fully understand the purpose of
> Promises.  Nothing special happens, because this is an intended
> interaction mode.  Promises can have callbacks registered against them
> either before *or* after they've fulfilled; either way, they'll call
> the callback with their value as normal.  There's no such thing as
> late registration, because eliminating that precise pitfall is one of
> the major reasons Promises are better than Events for some things.
>

I was specifically looking at the algorithms included in the specification
and I could not discern whether that behavior was clearly stated. I
couldn't find a link between promise.then() invocation and invoking a
promise callback if that promise has already been fulfilled (unless calling
that callback is implicit in that process already which wasn't clear).


> The only relevant state machinery operations are the accept()/reject()
> methods on the resolver, but they just silently fail if called when
> the promise has already been fulfilled.
>
> ~TJ
>
Received on Monday, 29 July 2013 03:16:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC