We want map/flat iterator which simply consumes Iterator<T> and transforms next element on the fly, if necessary. Don't use intermediate singleton iterators.
That means, we should use simple stack. Method next will just take iterator from top of the stack and:
if iterator is empty, will pop it and try next value from the stack
if iterator.next is non-transformable, returns item
if item is transformable, it transforms, pushes generated iterator on stack and executes "next" again
Such strategy allows us to implement two things:
flatten without intermediate singleton iterators
flatten recursively, it is deep flatten
In fact, strategy described above is "recursive". If we want to have shallow flattening, we should check transformable only if the stack.size = 1
We want map/flat iterator which simply consumes `Iterator<T>` and transforms next element on the fly, if necessary. Don't use intermediate singleton iterators.
That means, we should use simple stack. Method `next` will just take iterator from top of the stack and:
- if iterator is empty, will pop it and try next value from the stack
- if iterator.next is non-transformable, returns item
- if item is transformable, it transforms, pushes generated iterator on stack and executes "next" again
Such strategy allows us to implement two things:
- flatten without intermediate singleton iterators
- flatten recursively, it is deep flatten
In fact, strategy described above is "recursive". If we want to have shallow flattening, we should check transformable only if the stack.size = 1
The question is, what to do with CQuery.flatIf/CQuery.flatWhile when we want to use Stream instead of Iterator.
If using Stream.flatMap we need to use singletonStream. What's more, we need to wrap generated flattened stream by flatMap again.
The question is, what to do with CQuery.flatIf/CQuery.flatWhile when we want to use Stream instead of Iterator.
If using Stream.flatMap we need to use singletonStream. What's more, we need to wrap generated flattened stream by flatMap again.
Probably we can write reasonable flatMapIf implementation using example above.
What's more, it is good workaround for JDK bug, much better than returning to iterator all the time.
There is reasonable flatMap implementation:
https://stackoverflow.com/questions/32749148/in-java-how-do-i-efficiently-and-elegantly-stream-a-tree-nodes-descendants/32767282#32767282
Probably we can write reasonable flatMapIf implementation using example above.
What's more, it is good workaround for JDK bug, much better than returning to iterator all the time.
We can write addintional, better IteratorUtils.flat too if we use strategy described above. It is simply unconditional, shallow flat.
Current version:
flat(Iterator<Iterator<T>> input)
Additional possible version:
flat(Iterator<T> input, Function<T, Iterator<T>> splitter)
We can write addintional, better IteratorUtils.flat too if we use strategy described above. It is simply unconditional, shallow flat.
Current version:
`flat(Iterator<Iterator<T>> input)`
Additional possible version:
`flat(Iterator<T> input, Function<T, Iterator<T>> splitter)`
Very important: we need to support preserving splitted value and returning it too. It means: item will be transformed to {data, splitted data...} instead of {splitted data...} alone.
It is possibly trivial: one flag which decides to return item first, even if it is transformable, put into last and our next method should split last item instead of the item retrieved from iterator-stack (retrieved item must be returned always if flag is enabled)
We need that if we want to implement #50 correctly in easy way (we don't want to loose interfaces which implements other interfaces, we want to return all of them, both parent and children).
At the level of non-recursive stream it is something like:
Very important: we need to support preserving splitted value and returning it too. It means: `item` will be transformed to `{data, splitted data...}` instead of `{splitted data...}` alone.
It is possibly trivial: one flag which decides to return item first, even if it is transformable, put into `last` and our `next` method should split `last` item instead of the item retrieved from iterator-stack (retrieved item must be returned always if flag is enabled)
We need that if we want to implement #50 correctly in easy way (we don't want to loose interfaces which implements other interfaces, we want to return all of them, both parent and children).
At the level of non-recursive stream it is something like:
```
stream.flatMap(v -> Stream.of(v).concat(splitme(v)) )
```
instead of
```
stream.flatMap(v -> splitme(v) )
```
or more precisely
```
stream.flatMap(v -> condition ? Stream.of(v).concat(splitme(v)) : Stream.of(v) )
```
instead of
```
stream.flatMap(v -> condition ? splitme(v) : Stream.of(v) )
```
recursive version (even more complicated):
```
stream.flatMap(v -> condition ? Stream.of(v).concat( flatIf(condition, splitme(v)) ) : Stream.of(v))
```
instead of
```
stream.flatMap(v -> condition ? flatIf(condition, splitme(v)) : Stream.of(v) )
```
We want map/flat iterator which simply consumes
Iterator<T>and transforms next element on the fly, if necessary. Don't use intermediate singleton iterators.That means, we should use simple stack. Method
nextwill just take iterator from top of the stack and:Such strategy allows us to implement two things:
In fact, strategy described above is "recursive". If we want to have shallow flattening, we should check transformable only if the stack.size = 1
Again, this way will give us:
flatIfflatWhileThe question is, what to do with CQuery.flatIf/CQuery.flatWhile when we want to use Stream instead of Iterator.
If using Stream.flatMap we need to use singletonStream. What's more, we need to wrap generated flattened stream by flatMap again.
There is reasonable flatMap implementation:
https://stackoverflow.com/questions/32749148/in-java-how-do-i-efficiently-and-elegantly-stream-a-tree-nodes-descendants/32767282#32767282
Probably we can write reasonable flatMapIf implementation using example above.
What's more, it is good workaround for JDK bug, much better than returning to iterator all the time.
We can write addintional, better IteratorUtils.flat too if we use strategy described above. It is simply unconditional, shallow flat.
Current version:
flat(Iterator<Iterator<T>> input)Additional possible version:
flat(Iterator<T> input, Function<T, Iterator<T>> splitter)Very important: we need to support preserving splitted value and returning it too. It means:
itemwill be transformed to{data, splitted data...}instead of{splitted data...}alone.It is possibly trivial: one flag which decides to return item first, even if it is transformable, put into
lastand ournextmethod should splitlastitem instead of the item retrieved from iterator-stack (retrieved item must be returned always if flag is enabled)We need that if we want to implement #50 correctly in easy way (we don't want to loose interfaces which implements other interfaces, we want to return all of them, both parent and children).
At the level of non-recursive stream it is something like:
instead of
or more precisely
instead of
recursive version (even more complicated):
instead of
done: iterator version
todo: stream/spliterator version
todo:
CQuery#deepFlatIfandCQuery#treeFlatIftodo: stream/spliterator version. Now we just delegate all CQuery
flatto IteratorUtils. That means we are not parallelizable.todo: we should write optimized versions for
CQuery#eachtoo