explode

Brian Goetz brian.goetz at oracle.com
Wed Feb 6 16:16:15 PST 2013


>        Stream<U> flatMap(FlatMapper<T, U>)
>        Stream<U> flatMap(Function<T, Stream<U>>)
>
> To make sure I understand: would these two behave identically? Would
> they imaginably perform comparably?
>
>      foos.stream().flatMap((t, consumer) ->
> t.somethingThatGivesAStream().forEach(consumer))
>      foos.stream().flatMap(t -> t.somethingThatGivesAStream())

Currently, they would behave identically.  The T -> Stream<T> form is 
not strictly necessary, since it can be written in terms of the other, 
but people will find it more convenient.

One place where they might not behave identically in the future is that 
since streams are lazy, we might be able to make:

   integers.flatMap(i -> anInfiniteStream()).getFirst()

actually terminate, whereas

   integers.flatMap((i,consumer) -> 
anInfiniteStream().forEach(consumer)).getFirst()

will never terminate.  So the laziness-preserving aspect of Stream is nice.

The second would perform basically the same as the first.  But neither 
would perform as well as actually generating the results directly into 
the consumer.

> Second question, why "FlatMapper.OfInt" here, but "IntSupplier" etc.
> elsewhere?

Depends where FlatMapper lives.  If FlatMapper is a general SAM, then it 
would go in j.u.f. and we'd definitely use the IntFlatMapper convention. 
  However, I would lean towards making FlatMapper a type in j.u.s., in 
which case the naming convention more prevalent there is to use nested 
OfXxx classes.


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