On Mon, Apr 22, 2013 at 5:37 AM, David Bruant <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
