Le 22/04/2013 16:15, Mark S. Miller a écrit :
On Mon, Apr 22, 2013 at 5:37 AM, David Bruant <[email protected]
<mailto:[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.
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
