Scheduler name bike-shedding

[benlesh]

Currently the trampoline scheduler is named immediate, and the microtask scheduler is named nextTick. There is als

I propose that we rename immediate to sync. I say this because immediate sort of implies that the scheduled action is going to take place right away, and that's not really true. It's going to be bumped from it's current call stack and executed next, but synchronously.

For nextTick, it's a little more debatable, it's pretty aptly named, but I think it would be more descriptive if it were named microtask, because ultimately that's the goal. To schedule it as a microtask after the current frame but before things like setTimeout.

... which brings me to another thing, we don't have a scheduler based off of setTimeout or requestAnimationFrame. The latter is DOM-specific, but given that we're modular now, I think there's grounds for including it in this library, it's an important scheduler.

Once we land on these names, I'll be writing some improved documentation on the matter.

[staltz]

I see no objections to this...

[benlesh]

In talking to @chriscareycode, @abersnaze and @stealthcode at Netflix, there were a few other options presented for names around immediate in particular:

• queueImmediate: because it gives users the sense that scheduled items are being buffered in some way.
• trampoline: because it's a brand new word with no connotations in the JS community which may make it more memorable, and describes what it does in a way that can be googled.
• jenga: because it topples the call stack over with in the same event on the event loop. Again, descriptive and memorable.
• immediate: less favored because people have some idea in their heads of what "immediate" means.
• sync: Because you're scheduling, but it's synchronous. This was less well recieved.

... all parties thought that currentThread didn't make any sense to them because of JavaScript's lack of "real" multithreading.

[staltz]

Trampoline sounds the best IMO.

[kwonoj]

+1 for trampoline and 'currentThread didn't make sense ' both. (intrigued into 'jenga' for sec..)

[benlesh]

I'd be interested in thoughts from @zenparsing, @domenic, @wycats or @stefanpenner on this, as well. I'm sure this sort of scheduling has come up in conversations at the TC39, and they might have more specific vernacular we could leverage.

[mattpodwysocki]

@Blesh that's been the problems with transporting the names from runtime to runtime. CurrentThread has a history of doing recursive scheduling right, placing things in the right order whereas the immediate was indeed immediate.

Consider the difference:

const Scheduler = require('rx').Scheduler;

Scheduler.currentThread.schedule('bye', (self1, state1) => {
  self1.schedule('hi', (self2, state2) => console.log(state2));
  console.log(state1);
});
// => bye
// => hi

Whereas the immediate scheduler would do the following:

const Scheduler = require('rx').Scheduler;

Scheduler.immediate.schedule('bye', (self1, state1) => {
  self1.schedule('hi', (self2, state2) => console.log(state2));
  console.log(state1);
});
// => hi
// => bye

[mattpodwysocki]

@Blesh had I done it over again, I would have the following:

• Scheduler.asap for using the fastest transport mechanism available in a non-blocking fashion
• Scheduler.async for slower mechanisms such as setTimeout etc
• Scheduler.immedate once again for immediate scheduling
• Scheduler.sync for synchronous scheduling that would once again mimic the current thread implementation.

Trampoline is not a word I'd like to put into my API as it's an implementation detail that they don't really need to know nor care about.

[benlesh]

that's been the problems with transporting the names from runtime to runtime. CurrentThread has a history of doing recursive scheduling right, placing things in the right order whereas the immediate was indeed immediate.

I completely get it.

For RxJS 5, we've had the lack of a scheduler mean "immediate" as in "no scheduling at all, just call it".

Scheduler.asap for using the fastest transport mechanism available in a non-blocking fashion
Scheduler.async for slower mechanisms such as setTimeout etc
Scheduler.immedate once again for immediate scheduling
Scheduler.sync for synchronous scheduling that would once again mimic the current thread implementation.

I sort of like asap, for the "microtask" scheduler, but it's not really "as soon as possible". In fact, it conflicts a little with async, since it is indeed "async". I think timeout was never a bad name for a 100% setTimeout-based implementation of a scheduler.

[mattpodwysocki]

@Blesh and for the most part, RxJS v4 has done the same with immediate, bypassing when specified and just returning an empty Disposable since it wasn't really capable of being cancelled anyhow.

[zenparsing]

From my point of view the only kind of scheduling that makes sense is "job queuing" (called microtask queue elsewhere). : \

[zenparsing]

Therefore I don't see the point in all of these different (and confusing) names.

[benlesh]

Therefore I don't see the point in all of these different (and confusing) names.

Suppose you want to synchronously traverse a tree recursively and the tree is 1000 levels deep.

... that's why there is more than one scheduler. :)

[mattpodwysocki]

@zenparsng where you are coming from and where we are, are two different spots. There is the want, especially on the ES-Observable, to make everything async, hence the microtask. Here, we want the swappable concurrency layer to choose which is right for us, like requestAnimationFrame, nextTick, setImmediate or queued as it were.

[trxcllnt]

@Blesh btw I have the RequestAnimationFrame Scheduler in a branch.