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

[Sam Pullara]

Agree 100%.

Sam

On Oct 7, 2013, at 1:31 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>>> 
>>> 
>>