Iterators wants filter(Iterable, Predicate)

[GoogleCodeExporter]

I immediately ran into a use-case where I wanted to create a filtered
iterator on a list. In other words, rather than

Iterator<Foo> it = Iterables.filter(myList, myPredicate).iterator();
or
Iterator<Foo> it = Iterators.filter(myList.iterator(), myPredicate);

I thought it would be nice to

Iterator<Foo> it = Iterators.filter(myList, myPredicate);

Original issue reported on code.google.com by e.e.coli@gmail.com on 12 Oct 2007 at 8:59

[GoogleCodeExporter]

List<Foo> list = Lists.filter(myList, myPredicate); would be nice too.

Original comment by gk5...@gmail.com on 12 Oct 2007 at 9:04

[GoogleCodeExporter]

Thanks for the suggestion.  Because we don't have a filtered List view, we 
recommend
that users who want a List result copy the data instead, by passing the result 
of
filter() to a List factory such as Lists.immutableList() or 
Lists.newArrayList().

If a filtered view of a List were produced, it would be Lists.filter().  
However,
unlike with Lists.transform(), here we have performance concerns.  The size(), 
get()
and indexOf() methods of the resulting list would all perform abysmally, and as 
these
methods are very fundamental to List behavior, you basically have an all-around
poorly-performing List.

So: are you sure you want it?  And if so, please hit me with those use cases!

Original comment by kevin...@gmail.com on 12 Oct 2007 at 10:45

[GoogleCodeExporter]

Wait, I misunderstood the original request.  My last answer addressed only gk's
add-on request.

The original request, now that I understand it, is really for just a wee bit of
syntactic sugar, which would, if applied consistently, end up greatly bloating 
the
size of the Iterators API.  As such, I'm against it.

Original comment by kevin...@gmail.com on 12 Oct 2007 at 10:48

[GoogleCodeExporter]

Fair enough.

Original comment by e.e.coli@gmail.com on 12 Oct 2007 at 11:17

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 16 Oct 2007 at 3:55

• Changed state: WontFix

[GoogleCodeExporter]

yeah, i agree that the filtered view would be pretty unfortunate.  i was 
envisioning a copy.  really, the only 
reason that i want it would be because a lot of apis use Collection over 
Iterable (even though i agree that it's not 
necessary in a lot of situations) and i get sick of making new lists all the 
time.  like e.e. i just wanted the sugar.

Original comment by gk5...@gmail.com on 19 Oct 2007 at 3:58

[GoogleCodeExporter]

Gotcha.

One thing - while a filtered List view has significant problems, a filtered
Collection or Set view may not be so bad.  The worst that can be said of these 
is the
O(n) size() and isEmpty()... but "plenty" of other JDK collections have an O(n)
size()... so we might still do that.

As for copying, what our API wants to do as *little* as possible is to secretly
choose Collection implementation classes for you that *we* think will be good 
enough.
 So, the idiom to create a filtered copy of a set is either

  Set<String> filtered = Sets.newHashSet(Iterables.filter(set, predicate));

or

  Set<String> filtered = Sets.newTreeSet(Iterables.filter(set, predicate));

etc. etc.

Original comment by kevin...@gmail.com on 19 Oct 2007 at 4:28