brian.goetz at oracle.com
Sat Oct 13 11:13:40 PDT 2012
Thanks for the suggestion. This is something we've considered and is still on the "being considered" list.
I think your suggestion is based on the assumption that you *already* have a collection lying around, and just want to return that. While that is the case often, it is also often not. In the case where you do not have a collection, replacing the existing FlatMap with something like you suggest would be both painful for the user (who has to create a garbage collection in the lambda) and also less efficient. So we could not *replace* this flatMap with one taking Mapper<T, Collection<T>> without making the API worse.
We could consider adding a convenience method
for the case you describe, but we have to be careful as we are bumping our heads up against erasure. We could only have one such method (since the erasure is flatMap(Mapper)). We would have to pick the signature carefully. Mapper<T,Collection>? Mapper<T,T>? Mapper<T,Streamable<T>>? If we pick Streamable (which is nice because that subsumes collections), array users are hosed -- we can't later add an array version.
On Oct 12, 2012, at 9:32 PM, Kin-man Chung wrote:
> The use of the operation flatMap exposes the Block interface. For
> instance, if one wants to get the list of all orders from all customers,
> one writes
> customers.stream().flatMap((s,c) ->
> In this case, the purpose of the parameter s is for buffering and
> streaming the elements and can really be hidden from the user. ( BTW,
> if we have "yield", we can write (c->c.getOrders().forEach(o->yield o)),
> but that's for another discussion.)
> I admit that the current flatMap is very general and powerful, but I
> think it is more common to flatten elements that are Streamable. Is it
> possible to add another flavor of flaMap that takes a function that
> returns a Streamable? If so, the above example can be simplified to
> customers.stream().flatMap(c -> c.getOrders())
> which is much more readable.
More information about the lambda-dev