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

[+es-discuss]


On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <erights@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.
> 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
>



-- 
    Cheers,
    --MarkM