W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: A design for Futures/Promises in DOM

From: Alex Russell <slightlyoff@google.com>
Date: Sun, 10 Mar 2013 19:27:30 +0000
Message-ID: <CANr5HFVNVOy+BXBVPM4Em+1dA67VH2TAASGR6mXv_-D8HCVjAA@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, Yehuda Katz <wycats@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, Jake Archibald <jakearchibald@google.com>, Jonas Sicking <sicking@mozilla.com>, "mounir@lamouri.fr" <mounir@lamouri.fr>, David Bruant <bruant.d@gmail.com>, Erik Arvidsson <arv@google.com>, Anne van Kesteren <annevk@annevk.nl>, Ryan Sleevi <sleevi@google.com>, Kris Kowal <cowbertvonmoo@gmail.com>
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!


> 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
Received on Sunday, 10 March 2013 19:28:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC