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

[David Holmes]

On 6/10/2013 7:39 PM, Brian Goetz 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.

I wonder how much of the HOL feedback came from people who had 
previously seen it this way?

What were all the arguments for renaming to substream? Have they somehow 
been invalidated or are we just deciding that this HOL feedback puts 
more weight on the old position?

David

> Sent from my iPhone
>
> On Oct 6, 2013, at 8:05 AM, Joe Bowbeer <joe.bowbeer at gmail.com
> <mailto: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
>> <mailto: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
>>
>>