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-observers
mailing list