Futures

David Bruant 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:
>
> 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


More information about the es-discuss mailing list