Futures (was: Request for JSON-LD API review)
Mark S. Miller
erights at google.com
Wed Apr 17 08:31:17 PDT 2013
On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <erights at google.com> wrote:
> 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.
> 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
> 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss