More flexibility in the ECMAScript part?

Mark Miller erights at gmail.com
Thu Apr 18 09:58:21 PDT 2013


Hi Tab, thanks for a concrete example. From previous experience in E with
similar promises, I agree that registering handlers later is quite natural,
but I didn't have time to hunt for an example.

It would indeed be silly to require such a counter-intuitive freshness
workaround in order to avoid a counter-intuitive diagnostic.



On Thu, Apr 18, 2013 at 9:43 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130418/1d777e52/attachment.html>


More information about the es-discuss mailing list