On Apr 22, 2013 5:29 PM, "Mark S. Miller" <erights at google.com> wrote:
>
> On Mon, Apr 22, 2013 at 8:16 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:
>>
>> From: David Bruant [bruant.d at gmail.com]
>>
>> > Especially given that it's only for a transitioning period where
native (or polyfilled) have to cohabit with previous library promises?
>>
>> This is a really bad misconception that you have repeated several times
now.
>
>
>
> Hi Domenic, I just repeated it too:
>
> > If [standard platform-provided ES promises] ever wins
> > definitively, so that there are no remaining libraries of
> > concern, it will no longer need the assimilation mechanisms
> > that enabled that co-existence; but by then it will be too
> > late to shed it.
>
> I agree that Promises/A+ are too minimal, that DOMFutures does not solve
the problems that need solving,

This is far too strong a statement. They do not solve *all* problems, but
the crack the hardest not: they add futures/promises to the design language
of the entire platform. We forget that value at our loss. The proposed,
minimal, initial Futures design is a starting point based on design
consensus. As that consensus expands, so can (hopefully will!) the API.

I'm happy to work with all who are interested on such extensions.

> and that the Q API you link to is an excellent start. But I'm actually
more hopeful that, after a transition period, a standard platform-provided
ES7 promises along the lines of Q might be good enough that other library
needs can be built on it rather than more directly on the underlying
platform. Nevertheless, the constraints imposed by this transition period
remain AFAICT inescapable, and so the conclusion -- assimilation -- remains
the same.
>
>
>
>>
>>
>> DOM Futures, and possibly ECMAScript promises, are practically
feature-less. They have `then`, `catch` sugar, a few static combinator
methods, and that's it. If you want to do anything serious with promises,
you're going to need a lot more than that. Check out the extensive API Q
provides, for example:
>>
>> https://github.com/kriskowal/q/wiki/API-Reference
>>
>> In particular, I and teams I have worked on in real-world projects use
`promise.finally`, the promise-for-object methods, the promise-for-function
methods, and the utility methods literally every day. (To say nothing of
the Node.js-interfacing methods.) Features like long stack traces have been
invaluable for us. When.js has similar extra capabilities beyond the
basics, and even RSVP (which is pretty lightweight) has `RSVP.hash` for
shallowly settling any promise properties of an object. And the Q ecosystem
is built around different fundamental primitives from DOM Futures which
allow things like promise for remote objects, promise pipelining, and the
like---use cases which are increasingly important.
>>
>> To think that users who are accustomed to this level of flexibility are
going to suddenly switch to DOM Futures/ECMAScript promises is very naive.
More likely, those will be used alongside more full-featured promises
returned from other parts of the system---forever, not just in some
transition period. Thus, interop is going to be necessary for an ergonomic
experience.
>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130424/5f12831a/attachment-0001.html>

On Apr 22, 2013 5:29 PM, "Mark S. Miller" <erights at google.com> wrote:
>
> On Mon, Apr 22, 2013 at 8:16 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
>>
>> From: David Bruant [bruant.d at gmail.com]
>>
>>> Especially given that it's only for a transitioning period where native (or polyfilled) have to cohabit with previous library promises?
>>
>> This is a really bad misconception that you have repeated several times now.
>
>
>
> Hi Domenic, I just repeated it too:
>
>> If [standard platform-provided ES promises] ever wins
>> definitively, so that there are no remaining libraries of
>> concern, it will no longer need the assimilation mechanisms
>> that enabled that co-existence; but by then it will be too
>> late to shed it.
>
> I agree that Promises/A+ are too minimal, that DOMFutures does not solve the problems that need solving,

This is far too strong a statement. They do not solve *all* problems, but
the crack the hardest not: they add futures/promises to the design language
of the entire platform. We forget that value at our loss. The proposed,
minimal, initial Futures design is a starting point based on design
consensus. As that consensus expands, so can (hopefully will!) the API.

I'm happy to work with all who are interested on such extensions.