Itera*s.removeIf(Itera*, Predicate)

[GoogleCodeExporter]

e.g.

class Iterables {
    public static <T> void removeIf(Iterable<T> items, Predicate<? super T>
predicate) {
        for (Iterator<T> iter = items.iterator(); iter.hasNext();) {
            if (predicate.apply(iter.next()))
                iter.remove();
        }
    }
}

Original issue reported on code.google.com by phol...@gmail.com on 3 Jun 2009 at 11:04

[GoogleCodeExporter]

Note that if your items are in a Collection, you can do

  Collections.filter(items, IS_BAD).clear()

and if not, well, an Iterables.removeAll(Iterable) method would suffice:

  Iterables.removeAll(Iterables.filter(items, IS_BAD))

I'm neither strongly for nor against this new removeAll() overload.

Original comment by kevin...@gmail.com on 3 Jun 2009 at 11:12

[GoogleCodeExporter]

Didn't realize that Collections2.filter gave a view whose clear() knocked out
matching elements -- nice.  I like removeIf and retainIf in that the method 
names are
very evocative -- it's very obvious what they do.  Collections2.filter().clear()
wasn't so obvious to my tiny Paul-brain.  However, if it throws the 
power-to-weight
balance of the API out of whack, I'm OK to leave re(tain|move)If out.

Original comment by phol...@gmail.com on 6 Jul 2009 at 7:37

[GoogleCodeExporter]

I forgot that Iterables.filter() returns an Iterable whose iterators are 
UnmodifiableIterators, so what I proposed won't work.  I think than an 
Iterables and 
Iterators method like you describe may be the right idea after all.

Name?
- removeIf?
- removeMatching?
- removeMatches?
- ?

Original comment by kevin...@gmail.com on 30 Jul 2009 at 6:40

[GoogleCodeExporter]

I'd suggest choosing names that are consistent with the limit / skip methods 
requested in Issue #192. (as far as I can tell, names for those methods are 
still up 
in the air as well).

There was same discussion on the mailing list about this too:

http://groups.google.com/group/google-collections-users/browse_thread/
thread/546efe01b7673a30/bbab2da99ae3dcf5?hl=en&q=The+names+take+/+drop+are+also+
used
+in+haskell+to+mean+the+same+thing,+and+the+naming+extends+to+the+list+filtering
+methods:

One suggestion: 
   * dropWhile (drop elements while the condition is true)
   * takeWhile (returns elements while the condition is true)
   * dropIf (drop all elements that exercise the condition)
   * takeIf (retain all elements that exercise the condition)

I prefer take/drop to retain/remove because of the textual similarity of retain/
remove.  I think it is easier to discern take/drop when reading / using 
intellisense.

Original comment by cresw...@gmail.com on 30 Jul 2009 at 9:01

[GoogleCodeExporter]

Although I also like drop/take, remove/retain corresponds with the respective 
Collection methods. Since those are semantically almost identical to what Kevin 
thinks 
of adding, I think consistency with those is more important...

Original comment by jim.andreou on 30 Jul 2009 at 9:12

[GoogleCodeExporter]

creswick: the methods you're describing are not the same ones the original 
poster is 
asking for.  This issue report is about methods that will actually mutate the 
passed-
in collection. Names like "dropWhile" and so forth are more appropriate to a 
utility 
which returns a filtered *view* of a source collection which remains unchanged.

Itera*s.removeIf() will be added, though probably not for 1.0.

retainIf() is unnecessary, as it's clearer to just say 
removeIf(Predicates.not(..)).

Original comment by kevin...@gmail.com on 7 Aug 2009 at 9:23

[GoogleCodeExporter]

We've implemented this but it will not make 1.0.

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:32

• Changed title: Iteras.removeIf(Itera, Predicate)
• Changed state: Accepted
• Added labels: post-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:45

• Added labels: Milestone-Post1.0
• Removed labels: post-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Added in r02.

Original comment by kevinb@google.com on 9 Apr 2010 at 5:37

• Changed state: Fixed

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:16

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:10

• Added labels: Restrict-AddIssueComment-Commit