The stream abstraction and substream() (original) (raw)

Jose jgetino at telefonica.net
Tue Apr 2 23:07:34 PDT 2013

When comparing the present Stream 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 and restricting to n=1 to keep it simple, the equivalent operation would be: 

                 T  next()

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 supports a kind of "skip" operation:

                  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 context, 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 stream?.

Or I missing someting important here?

Regards

More information about the lambda-dev mailing list