Re: Futures

On Mon, Apr 22, 2013 at 1:15 PM, David Bruant <bruant.d@gmail.com> wrote:

> Le 22/04/2013 17:16, Domenic Denicola a écrit :
>
>  From: David Bruant [bruant.d@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.
>>
>> 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<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.
>>
> I never suggested to give all that up. In the long term, all of that can
> be re-implemented on top of platform promises (with devtools support which
> is a significant bonus; you were talking about stack traces?) and maybe
> even improved based on the experience of current libraries.
> For the transition period, I suggested:
>
>  Each library can add:
>>     if(nativeFuture(p))
>>         p = wrapNativeFuture(p)
>>
>> to the beginning each of its method accepting a promise as argument (or
>> equivalent is the promise is in 'this')
>>
>> These 2 lines (+wrapNativeFuture) sound pretty practical to me for the
>> transition period.
>>
> It sounds like a reasonable compromise for libraries to work with built-in
> promises without imposing a burden on top of these.
>
>
>
> Dean Landolt wrote:
>
>> FWIW I disagree with him -- I strongly suspect that by the time this were
>> to all go down and a stable polyfill existed there'd already be too much
>> then-demanding code in the wild. There probably already is. And at that
>> point it's __proto__ all over again -- the standard will have no choice but
>> to respect then and the problem cannot be fixed :-/
>>
> There is a major difference with __proto__ which is that it is a platform
> de facto standard not a library de facto standard. __proto__ is already in
> the platform, it makes sense to standardize it as part of the platform.
> ".then" is a convention among a particular dev community (which I consider
> to be part of, but that's beyond the point); I'm not sure why the platform
> should follow that convention.
>

It was an imperfect analogy -- I was just saying there will be pressure to
include support for thenables (already in DOMFutures). If you believe
otherwise don't let me dissuade you -- I would absolutely love it if I were
proven wrong!


> By that logic, should the intersection of jQuery and Zepto's $ be included
> in the platform? Or the intersection of Underscore and Lodash for _ (there
> are minor differences)?
>

Apples and oranges -- these two are globals and have nothing to do with a
ducktyped defacto method.