Virtual extension methods -- a strawman design

Gernot Neppert mcnepp02 at googlemail.com
Mon May 17 00:47:04 PDT 2010


I find the notion of "default implementations of interface methods" a
little strange.
Isn't that an oxymoron?

In my understanding, an interface declares the set of methods that a
are needed to implement the functionality that the interface was
designed to provide. If any one method can be implemented by means of
calling other interface methods, then it is strictly speaking not
necessary at all. *)

So, if one comes up with a new method for an existing interface, I see
two possibilities:

1. The method can be expressed by invoking other methods. Then, why
not simply do that? I can see nothing bad about
"Collections.sort(List<?)" or similar static helpers.

2. The method is "original" in its declared functionality. Thus, it
can not be expressed by invoking existing methods. Thus, how can you
provide a default implementation?


Here's this reasoning applied to an example that pops up frequently
when extension methods are mentioned:
A "filter" method on Collections.

1.hypothetical method declaration (modifying operation):

/**
* Filters this collection.
* Removes all elements from this collection that do not satisfy the condition.
* @return true if the collection changed due to the filtering.
*/
public boolean filter(boolean #condition(E));

This method can be easily implemented "externally", i.e. by means of
iterating over  the collection and removing elements.
What would be gained by making this an interface method?

2.hypothetical method declaration (non-modifying operation):

/**
* Returns the filtered content.
* Returns a collection of the same type as this collection that
contains only those elements
that satisfy the condition.
* @return the filtered collection.
*/
public Collection<E> filter(boolean #condition(E));

This method cannot be implemented "externally" because of the
necessity to create a collection of the same type.
I see no reasonable way to provide a default implementation!








*) And yes, I do think that java.util.Collection is already bloated.
Methods such as "addAll" do not belong there!


More information about the lambda-dev mailing list