Re: A design for Futures/Promises in DOM

Hey Mark,

On Thu, Mar 7, 2013 at 5:13 PM, Mark S. Miller <erights@google.com> wrote:

> [+kriskowal]
>
> Hi Alex, there is a strawman <
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> that has
> co-evolved through these discussions to be largely compatible with Promises
> A+, Q, and DOMFuture where they overlap. As several have advised, this page
> should be broken up into modular pieces. Also, we should recognize the
> great work Domenic and Kris have done co-evolving Promises/A+ <
> https://github.com/promises-aplus> and Q <https://github.com/kriskowal/q>.
> Through these discussions and others, they have effectively served as an
> informal but working standards process.
>

+1 to that.


> Part of your DOMFuture idl says "Compatibility with existing
> promises/futures/deferreds libraries or terminology is a non-goal." When I
> first read this, my inclination was to write off DOMFuture as irrelevant.
> Clearly if such compatibility is a non-goal, then those other efforts
> (including my own) should treat compatibility with DOMFuture as a non-goal.
> Fortunately, you managed the DOMFuture discussions in practice in a
> reasonable and productive manner, such that all sides could treat
> convergence as a mutual goal, which I believe we've already largely
> achieved. I think we're close.
>

The non-goal statement was there to prevent premature constraints on a
design; if it was possible to design a better Promise/Future API, I wanted
to make sure DOM was the beneficiary of that process. Given that where
we've ended up is *entirely* A+ compatible, I think that's just more proof
that both designs have stood up well under intense, separate scrutiny.
Indeed, the DOMFuture polyfill now passes all of the A+ tests; that also
makes me think we're very close.

A couple of questions that I wanted this list's help with:

  * The current API name is "Future", creating a global constructor with
that name. This feels potentially future-hostile (har har) should ES7
introduce a class of the same name. A previous version used "DOMFuture" to
make way for this eventuality, hopefully creating the possibility that we
could eventually re-cast the DOM class as a subclass of the ES-native type.
If there's hope we can do it in ES quickly and without changes, then a name
change might not be needed (implementations can just swap their DOM version
for the ES one). But I don't have any sense for what this group thinks
about that possibility. Thoughts?
  * There's active discussion on the "isThenable" question which I think
could use more eyes: https://github.com/slightlyoff/DOMFuture/issues/41

Once we feel like we're close, I'll work up a straw-man and Anne
VanKesteren has agreed to write the DOM version. I'm hopeful we can get
this under steam in implementations ASAP!

Thanks!


> On Thu, Mar 7, 2013 at 8:50 AM, Alex Russell <slightlyoff@google.com>wrote:
>
>> Hi all,
>>
>> With the find folks on the CC list, I've been working for the past
>> several months on a design for Futures (need "Promises") that are mutually
>> acceptable to the interested TC39 members as well as key DOM API designers.
>>
>> This work is the fallout from the thread started here last year:
>>
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2012-November/thread.html#26188
>>
>> A public IDL design and p(r)ollyfill are now available:
>>
>>    https://github.com/slightlyoff/DOMFuture/
>>
>> Many issues regarding the design are currently under discussion:
>>
>>    https://github.com/slightlyoff/DOMFuture/issues?page=1&state=open
>>
>> The largest concerns about the core API semantics appear to be settled:
>>
>>    https://github.com/slightlyoff/DOMFuture/issues?page=1&state=closed
>>
>> Next steps:
>>
>> Barring major objections, I would like to propose that we move this
>> design forward in both DOM and in ES. If there is support, I will make an
>> ES straw-man to capture the invariants of the design while continuing to
>> work with DOM authors and designers to move this design into the web
>> platform in preparation for the longer-term project of importing it (or a
>> subset of it) into ES proper.
>>
>> Thoughts?
>>
>> Thanks
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>