Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
We've implemented this but it will not make 1.0.
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:32
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:45
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:57
This issue has been moved to the Guava project (keeping the same id number).
Simply replace 'google-collections' with 'guava-libraries' in your address
bar and it should take you there.
Original comment by kevinb@google.com
on 5 Jan 2010 at 11:09
Original issue reported on code.google.com by
phol...@gmail.com
on 3 Jun 2009 at 11:04