Moving processArrayAsync to Uize

[timcarter]

We've been thinking of moving Uize.Comm.processArrayAsync to Uize and perhaps renaming it to Uize.forEachAsync. We've been using the method in several places throughout our codebase and would prefer to remove the requirement that Uize.Comm be pulled in just for its use.

Unless there are any objections, we'll take care of it in our branch and issue a pull request at a later date. We'd of course maintain the original method as a pointer to the new one.

[UIZE]

What I've been finding most useful in recent experience is the ability to process an array of elements using a forEach type of semantics, but where the iteration handler for an iteration may be either synchronous or asynchronous. It might be that the implementation of the iteration handler changes from being always synchronous to always asynchronous (or vice versa), or it may be that the iteration handler process could be sync or async depending on the element being processed. In the case of the handler always being synchronous, you still want to be able to advance using a callback type signature, but you don't want to blow the call stack. The forEach method can detect that and process the array in batches of sync iterations, broken up by ones that were async. Another useful technique is to force all iterations to be async, but only if the handler called back synchronously. The question is whether, going forward, we want to make this just a utility belt method, or if we want to create a dedicated module for this type of iterator / loop.

[UIZE]

I've been toying around with the idea of creating a Loop module, for implementing a Loop object that is versatile enough to support sync vs async, breaking, cycling, and properties for observing the iteration progress. In other words, not as lightweight as a native for or while loop, but more for situations where you want to be able to control an iteration and make a loop observable and controllable. You could also, using this approach, define a loop and then hand it to someone else to start, stop, observe, etc. Such an object may also support the JavaScript iterator style interface, so you would be able to loop through it using a for...in loop, but others could be hooked into its progress through its properties and events.

[BenAtZazzle]

Are you suggesting that forEach and forEach would be combined? It seems like that would be overkill, especially having to detect the came. For the most part, you know ahead of time whether or not the handler is synchronous or asynchronous, so having two separate methods would make sense.

What if we moved it into Uize.Data since it deals with the data processing? The key really is to move it out of Uize.Comm because 1) it gets lost there 2) you don't want to pull in the Uize.Comm stuff if you don't have to and 3) outside of the web context (saw Photoshop), include Uize.Comm really doesn't make sense.