Closed gissuebot closed 9 years ago
gissuebot
commented
9 years ago Original comment posted by kevinb9n on 2009-06-03 at 11:12 PM
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.
gissuebot
commented
9 years ago Original comment posted by pholser on 2009-07-06 at 07:37 PM
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.
gissuebot
commented
9 years ago Original comment posted by kevinb9n on 2009-07-30 at 06:40 PM
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?
gissuebot
commented
9 years ago Original comment posted by creswick on 2009-07-30 at 09:01 PM
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.
gissuebot
commented
9 years ago Original comment posted by jim.andreou on 2009-07-30 at 09:12 PM
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...
gissuebot
commented
9 years ago Original comment posted by kevinb9n on 2009-08-07 at 09:23 PM
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(..)).
gissuebot
commented
9 years ago Original comment posted by kevinb9n on 2009-09-17 at 05:32 PM
We've implemented this but it will not make 1.0.
Status: Accepted
Labels: post-1.0
gissuebot
commented
9 years ago Original comment posted by kevinb9n on 2009-09-17 at 05:45 PM
(No comment entered for this change.)
Labels: -post-1.0, Milestone-Post1.0
gissuebot
commented
9 years ago Original comment posted by kevinb9n on 2009-09-17 at 05:57 PM
(No comment entered for this change.)
Labels: Type-Enhancement
gissuebot
commented
9 years ago
Original issue created by pholser on 2009-06-03 at 11:04 PM
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(); } } }