For the reference, both queues have been implemented by @jmalloc via reactphp/reactphp#234 and reactphp/reactphp#249 respectively. Let's ping @jmalloc, perhaps you can share your view on this?

The latter also has some discussion on this:

here's probably some discussion to be had about how necessary this is. I think it is necessary, as without it there is no way to execute user code on each tick of the engine without starving IO/timers (nextTick is too greedy).
The implementation is identical to nextTick, except that callbacks registered inside an existing futureTick handler will not be processed on the same tick. In other words, when the future-tick queue is processed, only the callbacks that were already on the queue are executed. With this implementation, futureTick should generally be favoured over nextTick unless you specifically need the stricter guarantees of nextTick.

Long story short, cooperative multitasking will likely depend on futureTick() instead of nextTick().

There's also some confusion about this topic in #28.

I'm still curious if we have a valid use case for nextTick(), i.e. explicitly starving the event loop if we repeatedly add events to the loop. Otherwise, I'd suggest removing the nextTick() method as per this PR.

For what it's worth, nodejs also has:

• https://nodejs.org/api/timers.html#timers_setimmediate_callback_arg (similar to futureTick())
• https://nodejs.org/api/process.html#process_process_nexttick_callback_arg (similar to nextTick())

For what it's worth, nodejs also has:

• https://nodejs.org/api/timers.html#timers_setimmediate_callback_arg (similar to futureTick())
• https://nodejs.org/api/process.html#process_process_nexttick_callback_arg (similar to nextTick())

Afaict there's also debate about which function should be used, e.g. see http://stackoverflow.com/a/15349865

I'm well aware of the differences between both functions. However, I have yet to find a valid use case for nextTick()…

👍 on removing next ticks, it just adds confusion without a real good use case for keeping them

I can't see any immediate reason to retain nextTick. For whatever it's worth, the only large project I have using React is Recoil and it does not use nextTick at all.

I'd also like to add that I was never quite happy with the name futureTick. Since this is a BC break anyway, maybe we could consider more appropriate names. $loop->defer($work); might make more sense?

I'm with @jmalloc renaming futureTick to defer is a great idea 👍

I'm ok with renaming and defer makes sense grammatically, however I do worry about the confusion of the word. React also houses the Promise library where invoking a defer call created a deferred object that can resolve or reject a promise object.

That's a valid concern for sure. I still personally prefer defer, but offer enqueue as a possible alternative. At any rate, I think it should be a verb :)

I'm with @cboden regarding the potential confusion of using defer but well that's actually what it does... maybe postpone? I do agree on the fact that the current futureTick and nextTick are awful names, after all we had the same discussion at the time of @jmalloc's PR from a while back and we couldn't come up with valid alternatives.

Back to the initial scope of this PR, I'm still torn about removing nextTick altogether but I don't have a strong and practical use case to support it.

Ye old thesaurus came up with a few options, my top ones:

• delay
• postpone
• mothball

I agree that defer is grammatically correct but, to me, it's synonymous with containing a promise object - which is not the case in this context.

The term schedule seems good enough to understand that you're deferring the task to other loop iteration. With enqueue, you don't know if you are enqueuing for this loop iteration or not, It is not as explicit as schedule.

As a non experienced user of reactphp (I started to read the code last week), my first thought after read defer was: this return a promise?

👍 for removing nextTick. Also 👍 for renaming futureTick to defer.

I just noticed that I used nextTick only one time in predis\async to fix an issue but it's old stuff (and so damn un-Reacty anyway at this point) and I guess futureTick would've probably worked anyway. All in all I wouldn't mind having nextTick removed. As for futureTick, despite being an awful name I still have doubts about renaming it to defer.

Btw, the async-interop loop also uses defer: https://github.com/async-interop/event-loop/blob/master/src/Loop.php#L148

Technically, this PR is a BC break and if we are to accept this, this will be part of the upcoming v0.5 release.

However, I would vote for keeping the method names as-is for now at least. If we are to accept this PR, then we'll remove nextTick() and only futureTick() remains.

Empirical evidence seems to suggest that:

• Most consumers of this lib don't use either
• Those that actually use futureTick() could probably switch from nextTick() without affecting operation

This means that while this PR is a BC break, most consumers of this library are likely compatible with the current v0.4 as well as the upcoming v0.5 release.

I'm not saying futureTick(), defer() or anything else makes any more sense, but I'd vote to move this discussion to another release.

@clue Good point, agreed. 👍