Re: Futures

Le 22/04/2013 16:15, Mark S. Miller a écrit :
> On Mon, Apr 22, 2013 at 5:37 AM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     Le 22/04/2013 14:26, Kevin Smith a écrit :
>>
>>
>>         Thenable futures are uglier than branded futures, but also
>>         the only
>>         way to remain compatible with the various libraries that are
>>         out there
>>         today, which is something many people value.
>>
>>
>>     What about using a symbol for the `then` protocol?  Libraries can
>>     be upgraded to use the symbol as an alias for `then`.  It set up
>>     a dependency on ES6, of course...
>     And it doesn't address the compatibility problem people want to
>     address.
>     I personally wonder whether the compatibility with existing
>     libraries is so important. It should be pretty easy to wrap a
>     native future into a library future (aren't native futures already
>     Promise/A+ compatible?) and vice versa. Why isn't it enough to
>     help with compatibility with libraries?
>
>     Eventually, what will be the point of a promise library if there
>     is native support?
>
>
> This is the great irony. Even if standard platform-provided ES 
> promises win in the end, there will be a long transition period where 
> there are several co-existing libraries. In order for standard 
> platform-provided ES promises to win, it has to thrive in the 
> environment of that co-existence.
In my opinion, integration to other platform APIs is a legitimate unfair 
advantage of platform promises against existing libraries. This 
advantage is what will make platform promises win. Especially given that 
both the Future standard library and its integration in other platform 
APIs are polyfillable.
I believe we can agree that the Future standard is just the first step 
toward integrating more deeply in the platform and not just a built-in 
promise library.

Said otherwise, as soon as built-in futures are in, integrated in at 
least one other platform API, deployed in mainstream web browsers and an 
open source polyfill is available, why would a dev ever use a separate 
promise library?

Unless I'm missing something, platform Futures are doomed to win this 
battle.

> If it 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 would like a realistic way out of this dilemma.
Each existing library can wrap platform futures to build one of their 
own. That sounds realistic enough, doesn't it? That can be enough for 
Futures to become the new standard.
This would be pretty much the equivalent of "use DOM methods on native 
DOM nodes and jQuery methods on jQuery objects"
DOM methods play with and return DOM objects, jQuery methods plays with 
and generates jQuery objects (almost) and jQuery provides a 
one-directional way to turn a DOM object into a jQuery object.


> But after a tremendous number of messages on the promises/A+ site 
> about exactly this issue (please read or at least skim), I don't think 
> any of the alternatives are realistic. At 
> <https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-16244517> 
> I write:
>
>
>     The original E promise API which inspired all these others has no
>     assimilation. When I first heard about assimilation, I thought it
>     was a terrible idea, for many of the same reasons that underlie
>     many of the above objections. However, as I saw the JS promise
>     landscape evolve, I despaired more over a worse problem:
>
>     Several similar but different elephants in the room: jQuery
>     promises, WinJS promises, Q promises, and DOMFutures. All of these
>     but DOMFutures have enough installed base that they're not going
>     away. And re DOMFutures, never underestimate the ability of the
>     w3c to be an elephant even for premature "standards". Much code
>     will have to be written in an environment inhabited by multiple
>     such promise systems simultaneously. If none of these recognize
>     each other's promises as anything promise-like, then programmers
>     will face the burden of dealing with a "jQuery promise for a Q
>     promise for a WinJS promise for a DOMFuture for a number". Call it
>     the JQPFAQPFAWJPFADFFAN problem. I didn't see how we could get
>     from that situation to one with an agreed standard promise anything.
>
I wonder how frequent it is to have 2 promise libraries in the same 
runtime *and* want them to interact. Which is pretty much asking whether 
people import 2 DOM manipulation libraries and want these libraries to 
cohabit.
Isn't at least 80% of the case just one promise library interacting with 
the platform?
If it is, can the library-wraps-native-promise rule be enough?


>     Fortunately, the starting point for all of these elephants was so
>     similar that the Promises/A+ process was able to tease out and
>     codify a common-enough ground for all of these to agree on. This
>     is messy real-world standards work; as much politics and sociology
>     as technology and math. Given the constraints imposed by legacy,
>     we should all be overjoyed that the Promises/A+ community has been
>     able to extract something as beautiful as they did. But even if
>     they all agreed on exactly the same spec, so long as jQuery
>     promises only recognize jQuery promises as promises, and likewise
>     for the others, we would still have the JQPFAQPFAWJPFADFFAN problem.
>
>     Had ES6 with its unique symbols happened long before any of these
>     promise libraries, we could have used a unique "@then" symbol for
>     assimilation and so avoided the accidental collision @killdream
>     worries about above. Likewise, if all of these had stuck with the
>     E (or original Q) name "when" rather than renaming it "then", we
>     would have less accidental collision, and would be less irritating
>     to category theorists. (FWIW, I think "when" was a much better
>     term than "then" for this anyway. I am still unclear on the
>     history of how this got renamed.) Alas, it didn't turn out that way.
>
>     Given multiple promise systems that each recognize only their own
>     promises as promises, but which mostly agree on the meaning of
>     "then", assimilation turns out to be a surprisingly pleasant way
>     for these to co-exist. Given the actual situation we have to start
>     from, having this assimilation be based on duck typing on the
>     presence of a function named "then" is unfortunate, but there was
>     no other practical choice.
>
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.

David