W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Futures

From: David Bruant <bruant.d@gmail.com>
Date: Mon, 22 Apr 2013 19:15:13 +0200
Message-ID: <51757021.2010002@gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Anne van Kesteren <annevk@annevk.nl>, Brendan Eich <brendan@mozilla.com>, "Mark S. Miller" <erights@google.com>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, es-discuss <es-discuss@mozilla.org>
Le 22/04/2013 17:16, Domenic Denicola a écrit :
> From: David Bruant [bruant.d@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
Received on Monday, 22 April 2013 17:15:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC