Open kriskowal opened 4 months ago
It occurs to me that reduce
with a basis and governor is very different than (say) merge
with only a governor, so separate methods may make a lot of sense. I will try to find some time to elaborate (or connect with your prior reasoning)
Specifically, when there is a basis and concurrency, it makes sense for that basis be used to prime every concurrent job, both initially and whenever concurrency increases. When there is no basis, it only make sense for each job to draw a basis from the source. Regardless of order preservation, neither guarantees the order of merges, just that the ordered versions only merge adjacent values from the source stream, and that the basis might be interpolated between any of them.
Array.prototype.reduce is sensitive to call arity, to detect whether to begin with a base value or wait for the first iteration result. So, the governor argument forces the arity high enough to compel the interpretation of an undefined base result.
AsyncIterator.prototype.reduce
be insensitive to arity, defaulting the basis to undefined? In this world, governor can be a third positional argument without issue.AsyncIterator.prototype.reduce
be sensitive to arrity, always interpreting the presence of a governor as consent to treat the second argument as a basis.AsyncIterator.prototype
have a separate method; e.g.,reduceWithGovernor
,governedReduce
, orproduce
; that accepts a governor and optional basis?