Le 22/04/2013 17:16, Domenic Denicola a écrit :
From: David Bruant [[email protected]]
Especially given that it's only for a transitioning period where native (or
polyfilled) have to cohabit with previous library promises?
This is a really bad misconception that you have repeated several times now.
DOM Futures, and possibly ECMAScript promises, are practically feature-less.
They have `then`, `catch` sugar, a few static combinator methods, and that's
it. If you want to do anything serious with promises, you're going to need a
lot more than that. Check out the extensive API Q provides, for example:
https://github.com/kriskowal/q/wiki/API-Reference
In particular, I and teams I have worked on in real-world projects use
`promise.finally`, the promise-for-object methods, the promise-for-function
methods, and the utility methods literally every day. (To say nothing of the
Node.js-interfacing methods.) Features like long stack traces have been
invaluable for us. When.js has similar extra capabilities beyond the basics,
and even RSVP (which is pretty lightweight) has `RSVP.hash` for shallowly
settling any promise properties of an object. And the Q ecosystem is built
around different fundamental primitives from DOM Futures which allow things
like promise for remote objects, promise pipelining, and the like---use cases
which are increasingly important.
To think that users who are accustomed to this level of flexibility are going
to suddenly switch to DOM Futures/ECMAScript promises is very naive. More
likely, those will be used alongside more full-featured promises returned from
other parts of the system---forever, not just in some transition period. Thus,
interop is going to be necessary for an ergonomic experience.
I never suggested to give all that up. In the long term, all of that can
be re-implemented on top of platform promises (with devtools support
which is a significant bonus; you were talking about stack traces?) and
maybe even improved based on the experience of current libraries.
For the transition period, I suggested:
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.
It sounds like a reasonable compromise for libraries to work with
built-in promises without imposing a burden on top of these.
Dean Landolt wrote:
FWIW I disagree with him -- I strongly suspect that by the time this
were to all go down and a stable polyfill existed there'd already be
too much then-demanding code in the wild. There probably already is.
And at that point it's __proto__ all over again -- the standard will
have no choice but to respect then and the problem cannot be fixed :-/
There is a major difference with __proto__ which is that it is a
platform de facto standard not a library de facto standard. __proto__ is
already in the platform, it makes sense to standardize it as part of the
platform. ".then" is a convention among a particular dev community
(which I consider to be part of, but that's beyond the point); I'm not
sure why the platform should follow that convention.
By that logic, should the intersection of jQuery and Zepto's $ be
included in the platform? Or the intersection of Underscore and Lodash
for _ (there are minor differences)?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
