Re: Futures

On Mon, Apr 22, 2013 at 5:37 AM, David Bruant <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. 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. 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.
>
> 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.



-- 
    Cheers,
    --MarkM