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

[Joe Bowbeer]

slice is OK with me.  It partners well with skip and limit.


On Mon, Oct 7, 2013 at 1:47 PM, Sam Pullara <spullara at gmail.com> wrote:

> 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
> >>>
> >>>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131007/e1d925ca/attachment.html