On Thu, Apr 18, 2013 at 9:14 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>>> Also, can someone point me to a real-world example of delayed rejection
>>> handling?
>>
>> What do you mean by "delayed"? If that is: a promise has been rejected and
>> someone later add a .fail/.catch handler to it, then I've never done that
>> personally.
>
>
> Yes, that's what I mean.  Specifically, a real-world example where the
> rejection handler is added in "some future turn", using a fuzzy definition
> of that phrase.  A contrived example would be:
>
>     // Create a future and get the resolver
>     let resolver, future = new Future(r => resolver = r);
>
>     // Reject it
>     resolver.reject("error");
>
>     // Attach a rejection handler 5 seconds later
>     setTimeout(() => future.then(null, err => null), 5000);

There are several DOM APIs planning to use Futures which will return
the same future across multiple calls.  This future may have been
rejected in a previous turn.

An example of this is the Font Load API built with Futures that I'm
currently proposing: <http://www.xanthir.com/b4PV1>.  The Font#ready
function tracks the loading status of a single @font-face rule, so it
just returns the same future over and over.

These kinds of APIs *could* be done by tracking future state
internally, and always returning a fresh future matching the internal
state, but that seems silly.

~TJ

On Thu, Apr 18, 2013 at 9:14 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>>> Also, can someone point me to a real-world example of delayed rejection
>>> handling?
>>
>> What do you mean by "delayed"? If that is: a promise has been rejected and
>> someone later add a .fail/.catch handler to it, then I've never done that
>> personally.
>
>
> Yes, that's what I mean.  Specifically, a real-world example where the
> rejection handler is added in "some future turn", using a fuzzy definition
> of that phrase.  A contrived example would be:
>
>     // Create a future and get the resolver
>     let resolver, future = new Future(r => resolver = r);
>
>     // Reject it
>     resolver.reject("error");
>
>     // Attach a rejection handler 5 seconds later
>     setTimeout(() => future.then(null, err => null), 5000);

There are several DOM APIs planning to use Futures which will return
the same future across multiple calls.  This future may have been
rejected in a previous turn.

An example of this is the Font Load API built with Futures that I'm
currently proposing: http://www.xanthir.com/b4PV1.  The `Font#ready`
function tracks the loading status of a single `@font-face` rule, so it
just returns the same future over and over.

These kinds of APIs *could* be done by tracking future state
internally, and always returning a fresh future matching the internal
state, but that seems silly.