Ruben Verborgh
Ruben Verborgh
Seems like it's time to turn this convention into an officially meaningful thing.
Is the `SimpleTransformIterator` being used in performance-sensitive code? My goal for it was to be used for simple cases—and definitely not for chaining. I guess I should have been more...
Absolutely, thanks for finding this. We probably want: - Dedicated `MapIterator`, `FilterIterator`, … - A check within the `SimpleTransformIterator` that, if only `map` or `filter` are requested, one of the...
> I'd say this should be a new library of its own e.g. 'asynciterator-compose.js' Happy to have it here, really. Could be a separate file though (and maybe we could...
Thanks for all the work and please proceed, with the following caveats: - #45 is a semver.major so anything before that will be the last 3.x, and anything after that...
> is it the overall approach that does not convince you or is it the fact that we might have pushed it too far with things like `maybeMap`? At the...
> . Even when dealing with millions of elements, `Array#push()` consistently outperforms `LinkedList#push()` That is expected; but what we need to know is the behavior for repeated pushes and pulls,...
> `LinkedList`-backed `HistoryReader` [here](https://github.com/jacoscaz/AsyncIterator/tree/feat/faster-cloning) but saw no performance gains whatsoeve But that's because no data is ever pulled from it.
My plan is to wrap up AsyncIterator v3.x soonish; the moment we start tackling #45, we're in the v4.x territory. But I guess a v4.x alpha could be possible.
Could you elaborate on use cases?