Re: Futures

On Fri, Apr 26, 2013 at 9:01 AM, David Sheets <kosmo.zb@gmail.com> wrote:
> Domenic points out
> <http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0234.html>
> that DOM Futures currently do a recursive resolution which seems to
> violate these equivalences. I also don't see anything about these
> equivalences specified explicitly.

I find it very hard to follow the DOM Future spec explicitly.
However, when I asked Anne directly, he told me the opposite - that a
nested future would only do single-unwrapping.  Of course, I may have
asked it in a confusing manner, but I tried my best to be very
explicit and clear.

I've just now asked him again, and he confirmed it.  I also just
traced through the spec, and am pretty certain that he's right -
Future#then is monadic.

> Notably, it seems that DOM Futures is written in such a way as to
> abstract over resolvers though I don't see how to provide an
> author-defined FutureResolver. Can I simply construct a JavaScript
> object that quacks like FutureResolver and use the FutureInit
> constructor?

(Note: this is a tangent.  Not that that's bad, but anyone responding
to the previous paragraph probably doesn't need to respond to this
paragraph.)

FutureResolver is intimately tied to Future.  You don't want to
provide your own, because then it won't have any tie to the Future's
internal state.  The spec does some funky gymnastics that make it look
like it's constantly referring to the resolver, but that doesn't mean
you need to provide your own resolver - that just lets it
automatically deal with multiple callbacks registered on the same
future, etc.

~TJ

Received on Friday, 26 April 2013 17:44:26 UTC