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

[Brian Goetz]

Yeah, I agree with Paul that substream is the oddball and that the 
attempt to rename skip() to substream() was a failure.

If we have limit+skip, should the remaining substream(n,k) be renamed 
back to slice()?  WHich is what it was originally called.

On 10/7/2013 4:20 PM, Mike Duigou wrote:
>
> On Oct 6 2013, at 00:05 , Joe Bowbeer 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.
>
> Any consequences of this we should be highlighting in the documentation?
>
>> 2. Shouldn't both subStream-like methods have similar names?
>
> What to do with limit() then? The difficulty is that people see limit()
> and look for skip(). Unfortunately we can't make another overload for
> subStream() to provide limit() due to arity
>
> Mike
>
>
>>
>>
>>
>> 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
>>
>>
>