Renaming Stream.subStream(int) to Stream.skip(int)

[Paul Sandoz]

I am also revalidating my  own position because i forgot that the single argument variant of substream existed and thought it was skip too :-) cue alarm bells.

It's very common in other APIs to have a duality for such lazy operations; often called take and drop, in addition to predicate receiving takeWhile and dropWhile. Intuitively i think developers will look for such a duality (as observed in the HoLs).

I don't perceive skip as being any less lazy than limit. Nor do i perceive limit/skip being predominately associated with I/O-backed streams.

Furthermore, if/when we add predicate receiving methods it's gonna be awkward.

I would argue that substream(int, int) is actually the outlier (even though fundamentally limit/substream all point to the same implementation). FWIW if we want to ever consider these methods as more general concepts slice(int, int) might be a better name, thus not binding explicitly to stream.

Paul.

On Oct 6, 2013, at 11:39 AM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> Btw it used to be skip, and no one complained then they couldn't find the method.  Only after renaming to substream did the confusion start. 
> 
> Sent from my iPhone
> 
> On Oct 6, 2013, at 8:05 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> 
>> More arguments not to rename:
>> 
>> 1. The InputStream.skip(n) that Java programmers are familiar with is an eager consumer, where subStream(n) is a lazy view, more like subList.
>> 
>> 2. Shouldn't both subStream-like methods have similar names?
>> 
>> 
>> 
>> On Sat, Oct 5, 2013 at 10:48 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> On 4/10/2013 8:02 AM, Mike Duigou wrote:
>>>> Hello all;
>>>> 
>>>> A bit of feedback from the recent JavaOne hands-on-lab is that people have trouble finding the correct API to skip entries. The Stream.limit(count) operation and Stream.subStream(from,to) are easily found but new users fail to find the Stream.subStream(from) operation. One suggestion has been to rename the Stream.subStream(from) to Stream.skip(count).
>>>> 
>>>> The docs for Stream.subStream() also be updated to say something similar to "source.stream().subStream(from,to) produces the same set of elements in the same encounter order as source.stream().skip(from).limit(to-from)".
>>> 
>>> My suspicion is that people are taking their I/O stream knowledge and trying to map that to general Streams, hence looking for a "skip" operation. I can't convince myself that this is worthwhile changing given that it really produces a substream. Plus the I/O usage can be somewhat different as you often decide what to skip based on what has already been read, but with streams that won't be the case.
>>> 
>>> David
>>> 
>>> 
>>>> I will go ahead with a renaming patch on Monday unless there objections. Any counter proposals should be *very* narrow in scope--we're past the point were we can do redesign.
>>>> 
>>>> Mike
>>