Why no return a collection when possible?
jgetino at telefonica.net
Sat Aug 4 22:52:38 PDT 2012
> No, this is incorrect. On the source side, Collection is-a Iterable. So
consuming a collection is no problem. On the destination side, there's the
into() method. If
> you want a Collection, use that. If you don't need a Collection, don't
pay to instantiate one and copy all the elements when you don't need to.
This is why in these cases I don't like to use into() to get a Collection. I
prefer to use AbstractCollection to get a Collection without copying its
elements. The problem is that the code is not so neat and I have to write
one more line of code invoking the static method.
The AbstractCollection class places Iterables very close to unmodifiable
Collections, only the size() must be provided. Your new iterables are in
fact filling this gap with the count() method.
>In neither case is there a "major" refactoring of any kind.
I started to do this in my code, but there were too many changes that I got
afraid to broke many things. I will try it again for sure when the final
decission on Iterables/Streams has been taken.
More information about the lambda-dev