Guarantee future-turn resolutions

[jsor]

At the moment, we're not guaranteeing future-turn resolutions (which basically means, that callbacks should always be called asynchronously, read this).

All major JavaScript libs guarantee that (when.js does not at the moment, but will in their next major release).

We have 2 options.

1. We do not guarantee future-turn resolutions

   We keep it simple. Methods in When can stay static and creating Deferred's is as simple as doing $d = new Deferred. We should note that in the docs, so that developers are aware that there is no guarantee about if a promise will resolve asynchronously or synchronously.

2. We do guarantee future-turn resolutions

   This would couple React/Promise to the EventLoop (or at least to some kind of QueueProcessor for which we have an EventLoop adapter). We would have to make When non-static (and require the EventLoop or a QueueProcessor in the constructor which will be passed to Deferredinstances) and it will most probably become some kind of global entry point for creating promises and deferreds.

[jsor]

To get an idea, checkout the future-turn-resolutions branch.

Consumers of React/Promise would then most probably pass around a "global" React\Promise\When instance to create Deferreds and Promises, something like:

$when = new React\Promise\When(new React\Promise\EventLoopQueueProcessor($loop));

$deferred = $when->defer();
$promise = $when->resolve($value);

[igorw]

I want to keep this ticket open until we have a specific case that would benefit from the future-turn guarantee. As I said previously, I do not like coupling promises to the loop and would like to avoid it if possible.

Another unresolved issue is that we don't even know yet if it is possible to implement a fast-enough nextTick function for the libevent and libev loops. And it doesn't make sense to merge this patch before we have an answer to that.

[jsor]

As a reminder: http://thanpol.as/javascript/promises-a-performance-hits-you-should-be-aware-of/

[jsor]

See #28