Re: Futures

Sorry for the late post. Just wanted to agree with you assessment of the
landscape and options. We should not let theoretical purity poison the
utility of this feature.
On Apr 22, 2013 4:15 PM, "Mark S. Miller" <erights@google.com> wrote:

> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>