Fwd: Re: Stream.limit() - puzzler/bug/feature

Remi Forax forax at univ-mlv.fr
Thu Nov 15 11:16:14 PST 2012


This sprang up on the lambda-dev list and Brian ask me to transfer it to 
the EG list,
given that the last messages only implied people of this EG, I have 
copy/pasted these messages.

The problem is how to deal with stream that are created from IO objects ?
Should the implementation throws a runtime exception if such a stream 
are iterated twice
by a forEach by example ?

Rémi


Brian wrote:
 > A related question is what should happen in this case:
 >
 >  T first = stream.findFirst();
 >  T second = stream.findFirst();
 >
 >This "accidentally" works in the current serial impl, but is in 
general a nightmare.  Terminal ops should probably "close" the stream.


Sam wrote:

> This was my thinking when I read the example. Not sure if that is practical but it might reduce errors such as the one described.
>
> Sam

On Nov 15, 2012, at 9:36 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/15/2012 06:22 PM, Brian Goetz wrote:
>> The best way to think about it is that a Stream is more like an Iterator
>> than a data structure.  There is some abstract source of data somewhere
>> (it might be in a data structure, or might be generated from a function,
>> or read from a network), and a series of transformations applied to the
>> data between the source and the consumer.  Streams can additionally
>> execute using parallelism, if requested.
>>
>> Stream constructs like:
>>
>> Stream<Person> s = people.stream()
>>                           .filter(p -> p.getLastName().equals("Smith")))
>>
>> do not do any filtering on construction.  It simply says "there's a
>> stream source, the collection 'people', and when you consume from the
>> stream s, you'll get the results of filtering the source values."
>>
>> The confusion in Dmitry's example is akin to multiple activities reading
>> from the same IO channel -- they might interfere with each other over
>> who gets the next value, and any buffering that any consumer does may
>> confuse other consumers.
>
> Maybe the implementation should protect users to use two aliases of a
> non-replayable stream.
> Using the example of Dmitry, if the stream is an IO channel, the second
> call to limit() or to any method of 's' should throw an
> IllegalStateException.
>
> Rémi
>



More information about the lambda-libs-spec-observers mailing list