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
