Enhancement: Create Lists.filter, Iterables.reduce, Lists.removeByIndex

[GoogleCodeExporter]

Collections has filter, which takes a Collection and returns a Collection.
 Iterables has filter, which takes an Iterable and returns an Iterable.  It
is useful to be able to filter a List and get a List back.  I suggest
adding Lists.filter for this.

Reducing an Iterable to one value by applying a Function over each element
and the accumulator before it is useful.  Here are four possible signatures
for Iterables.reduce:

1. public static <T> T reduce(Iterable<T> iterable, Function2<T, T, T>
function)

2. public static <T> T reduce(Iterable<T> iterable, Function<Pair<T, T>, T>
function)

3. public static <T> T reduce(Iterable<T> iterable, Function<T, Function<T,
T>> function)

4. public static <T> T reduce(Iterable<T> iterable, Reduction<T> reduction)

For completeness, Function2, Pair and Reduction:

interface Function2<T, U, R> { R apply(T t, U u); }
interface Pair<T, U> { T first(); U second(); }
interface Reduction<T> { T reduce(T accumulator, T element); }

Therefore I suggest adding Iterables.reduce.

It's useful to be able to remove a number of elements from a List by their
index, producing a new List rather than modifying the existing one.  It is
error-prone for a caller to do this themselves, as the indices necessarily
change between each removal.  The indices would need sorting and duplicates
ignoring or rejecting if the implementing code is to be simple.

Therefore I suggest adding Lists.removeByIndex.

I can write these and supply tests (they are already written) in the same
style as the rest of the Google Collections library, if you would be likely
to include them.

Original issue reported on code.google.com by ricky.cl...@gmail.com on 15 Oct 2008 at 8:19

[GoogleCodeExporter]

Thanks for the suggestions.

We decided against including a list-filtering method, for the the following 
reasons.
The most commonly used features of a list, compared to an arbitrary collection, 
are a
well-defined iteration ordering and random access by index. 
Collections2.filter()
already keeps the iteration order of the provided collection. Retrieving a 
value from
a filtered list by index is slow, since an iteration across the list, up to the
desired index, is needed. Between the possibility of slow performance and the
complexity of a filtered list implementation, it seemed better to omit the 
method.
Collections.filter(list, predicate) or
Lists.newArrayList(Iterators.filter(list.iterator(), predicate)) would be better
solutions in most situations.

Regarding reduce, my main concern is that functional programming is generally so
verbose in Java, making simple iteration logic better in most cases, at least 
for an
arbitrary reduction function. I'm not convinced that an arbitrary reduce method 
would
make the calling code more readable. Now, some of our methods, such as
Ordering.max(E, E, E, E...) may be viewed as reduces with a fixed composition
function, and additional methods of that sort might be worthwhile.

Your Lists.removeByIndex() idea is plausible. However, when considering the 
code I've
written or reviewed, I can't think of any cases when such a method would have 
been
useful. Do other people think that such a method would be called sufficiently 
often
to justify adding it to the library?

Original comment by jared.l....@gmail.com on 15 Oct 2008 at 6:19

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

We won't add any of the proposed methods to the library, since they probably 
wouldn't
be called sufficiently often.

Original comment by jared.l....@gmail.com on 17 Oct 2008 at 6:26

• Changed state: WontFix

[GoogleCodeExporter]

Issue 276 has been merged into this issue.

Original comment by cpov...@google.com on 26 Oct 2009 at 6:01

[GoogleCodeExporter]

>> We won't add any of the proposed methods to the library, since they probably 
wouldn't
be called sufficiently often.

What is the problem of having 3 methods making the library complete?
How have you decided that the number of use cases is small? How have you count 
opinions?

Right now I have to code it myself. And the bigger disappointment is that even I
spend not too much time for coding in general my code won't be STABLE initially.

Please fix this. You have to help people to have complete tool even if some 
part of
it are not perfect. Let army of google-collect consumers decide what to employ. 
Don't
decide instead of us.

Original comment by koval...@gmail.com on 28 May 2010 at 10:52

[GoogleCodeExporter]

I can't say how common this is, but I needed it.  I used 
"Lists.newArrayList(Iterators.filter(list.iterator(), predicate))" mentioned 
above.  Eventually, I wound up here, because I couldn't believe that the 
solution I found was the best way.

Original comment by curt...@gmail.com on 15 Dec 2010 at 10:35

[GoogleCodeExporter]

I'd like to add my support for a reduce function. The argument that functional 
programming in Java is too verbose is applies equally to the transform method 
but that exists and I use it all the time as I would a reduce method. I agree 
that the library just seems incomplete without it

Original comment by rupert.b...@guardian.co.uk on 17 Jun 2011 at 10:19

[GoogleCodeExporter]

It's interesting to me that the WontFix is because of perceived lack of use of 
the functions considering that filtering through a list is a very common use 
case of lists.

Original comment by chengt on 29 Sep 2011 at 8:11

[GoogleCodeExporter]

I would also like to see this.

PS, I found it very amusing that the post by Jared on 10/15/08 had:

"Lists.newArrayList(Iterators.filter(list.iterator(), predicate)) would be 
better
solutions in most situations."
and then:
"... my main concern is that functional programming is generally so
verbose in Java..."

To summarize:
Functional programming being verbose is 'main concern' for why not to implement 
new method -- suggests even more verbose syntax as workaround.

You could always just create the filter method and wrap the iterator solution 
you suggested.

Original comment by john.hin...@gmail.com on 22 Jan 2012 at 7:17