The stream abstraction and substream()
jgetino at telefonica.net
Tue Apr 2 23:07:34 PDT 2013
When comparing the present Stream<T> abstraction with other similar
abstractions I'm using in my code,
mainly byte streams for reading/writing binary files, I miss the most common
operations I use: doing limited reads of the stream.
For example a can read a byte, a short, a byte array with the following n
elements and so on.
For Stream<T> and restricting to n=1 to keep it simple, the equivalent
operation would be:
But for Streams supporting concatenation, a very clever design, the reading
operations has to return a Stream, so in the pipeline context
the operation should be in fact:
Stream<T> next(Consumer<T> c)
Reading the Stream documentation I see that Stream<T> supports a kind of
Stream<T> substream(long startingOffset)
Which is described as "producing a Stream consistent of the elements of
this stream, discarding the first startingOffset elements"
If you are not going to read these elements, I would prefer the name skip(n)
more than substream(n), because substream says little in the pipeline
almost everything produces a stream, and a filter can also be seen as
producing a kind of substream.
The problem with this operation is that it really skips n elemets doing
nothing with them. As you can't process them, you can't emulate a next()
operation for example.
So my question is, why not implement a more general operation instead (maybe
using other name)
Stream<T> substream(long n, Consumer<T>)
and give the user the chance of processing the first n elements of the
Or I missing someting important here?
More information about the lambda-dev