bruant.d at gmail.com
Mon Apr 22 10:15:13 PDT 2013
Le 22/04/2013 17:16, Domenic Denicola a écrit :
> From: David Bruant [bruant.d at gmail.com]
>> 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:
> 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:
> 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)?
More information about the es-discuss