To Stream.slice(fromInclusive, toExclusive) or Stream.slice(toSkip, limit) that is the question

[Paul Sandoz]

Hi Joe,

I tend to think of slice(s, l) as the fused (optimal) form of skip(s).limit(l). For parallel streams the the fused form will result in less wrapping and/or buffering (depending on the properties of the input stream). Documentation-wise we should probably include an api note on skip and limit referring to slice in this respect.

Paul.

On Oct 11, 2013, at 3:28 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> slice(start, end) would be more useful and more consistent with its use in
> other languages (Python, Perl).
> 
> In Python, the elements are start .. end-1 whereas the end is inclusive in
> Perl.  But I think the use of start:end is fairly consistent for most
> implementations of slice.
> 
> I claim this would be more useful because otherwise there's no difference
> between slice and skip(start) + limit(end-start)
> 
> --Joe
> 
> 
> On Thu, Oct 10, 2013 at 5:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> FWIW, this is what the semantics were originally, and they got modified
>> to be consistent with substring() when we renamed slice to substring()
>> originally.  So this is a reversion to where we were before.
>> 
>> 
>> On 10/10/2013 7:54 PM, Mike Duigou wrote:
>> 
>>> Hello all;
>>> 
>>> In the review of the renaming patch for Stream.substream() -> slice()
>>> Brian asked me to consider also changing the semantics of the
>>> parameters from the current Stream.slice(fromInclusive,**toExclusive).
>>> The rationale is that we then have only one sense of usage in the
>>> parameters for skip/limit/slice. This also makes slice() more
>>> obviously equivalent to skip(toSkip).limit(limit). I am inclined to
>>> agree with him that using the same semantics for the parameters
>>> across the three methods has value.
>>> 
>>> I will go forward with changing to Stream.slice(toSkip,limit) before
>>> Monday assuming there is no outcry.
>>> 
>>> Mike
>>> 
>>>