RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate)

[Doug Lea]

On 09/04/2013 05:08 PM, Mike Duigou wrote:
> Hello all;
>
> The naming of the Collection.removeIf(Predicate) method has always been an
> uncertain choice. We've gone back and forth between naming it removeIf and
> overloading the existing removeAll(Collection) with a removeAll(Predicate).
> Now that all other library and language decisions seem to be settled it seems
> reasonable to make a final decision on this method naming.
>
> This patch proposes to use the removeAll(Predicate) overload. This choice is
> made to increase the discoverability of the method and to "reuse" the
> existing user understanding of the removeAll name. There is a minor source
> incompatibility induced by overloading the removeAll name--if explicit null
> is passed then a compiler cannot resolve which overload to use. Since null is
> not a legal value for either overload this source incompatibility is expected
> to only affect tests which check to see what response implementations return
> for null. The ambiguity can be resolved by providing a cast to either the
> Collection or Predicate types to select the appropriate overload.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024291/0/webrev/
>

I'm still mildly opposed.
One of the main consequences of how lambda matching rules
panned out is that  it is in general a bad idea to overload any
method accepting a lambda. I imagine that most tutorials etc
about designing with lambda will present this as the first
rule of thumb. So breaking it here for less-than-compelling
reasons sets a questionable example. The main uncompellingness
is that removeIf is a more descriptive name than removeAll.
As it is, people often refer to docs to check that the
existing removeAll(Collection)  is short for
removeAllElementsContainedInCollection(c).

I'm happy to accept majority vote on this though.

-Doug