Re: Futures (was: Request for JSON-LD API review)

Frankly, DOMFutures have nothing to do with the DOM, other than the fact
that the DOM would benefit from using them -- as would many other APIs.
There is nothing browser specific about this, and much that is JavaScript
specific. There is no reason for this to be under the jurisdiction of the
w3c. There is already a promise strawman cooking for ES7 at
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency . More
recently, the discussions for settling the promise spec have moved to
https://github.com/promises-aplus/promises-spec/issues?state=open . When
DOMFutures began, it was incompatible with promises in annoying ways.
Fortunately, through much good work by Alex on the DOMFutures side and many
people on the promises side, DOMFutures is now mostly compatible with
Promises/A+. I respect the work Alex has done on this. But it is still
proceeding within the wrong organization.

The main argument I've heard for proceeding with w3c/DOMFutures rather than
tc39/promises is that the DOM can't wait for tc39 to get around to
standardizing promises in ES7. But we should have our eyes open to the
consequences. As Crockford says (paraphrasing Knuth) "Premature
standardization is the root of all evil." The likely result of DOMFuture
proceeding in this way is that it will be wrong, ES7 will be stuck with it
and mostly unable to fix it, and we will all be stuck with the consequences
for a very very long time.

As with Object.observe, if the need for promises is that urgent, it needs
to be on an accelerated track with the JavaScript context -- as it already
de facto is at promises/A+. It should not be needlessly tied to the browser
or to w3c.



On Wed, Apr 17, 2013 at 7:24 AM, Norbert Lindenberg <
w3@norbertlindenberg.com> wrote:

> On Apr 16, 2013, at 16:55 , Tab Atkins Jr. wrote:
>
> > On Tue, Apr 16, 2013 at 8:30 AM, Markus Lanthaler
> > <markus.lanthaler@gmx.net> wrote:
> >> After a short discussion with Robin we decided to use method
> overloading to
>
> >> We also considered Futures but decided that introducing a normative
> >> dependency to the DOM spec is not acceptable at this stage.
>
> > In this case, your API is a textbook example of Futures.  You have an
> > async call which returns a single value, or an error.  You can't get
> > much more perfect than that.
>
> Maybe Futures should be in a separate spec? They don't seem to have any
> dependencies on DOM, and having them separate would reduce the bureaucratic
> hurdles for non-DOM specs to refer to them. Maybe eventually they could
> migrate into the ECMAScript standard library (currently known as ES chapter
> 15).
>
> Norbert
>
>
>
>


-- 
    Cheers,
    --MarkM