Virtual extension methods -- a strawman design

[Gernot Neppert]

2010/5/17 Reinier Zwitserloot <reinier at zwitserloot.com>:
> Advantage #2: In order to know what operations are possible on a given
> object, you check its methods. Whether you check the javadoc or just your
> IDE's auto-complete dialog, that's what you do. You cannot discover static
> helpers this way.

Very good point: having the object declare its methods is definitely
preferrable over having to find the right 'helper class'!

Maybe I came around wrong: actually, I wasn't so much arguing against
evolving interfaces.
I was arguing against blurring the difference between interfaces and
(abstract) classes by providing 'default implementations'

Consider this hypothetical line of events for a moment:

It is the year 2003. Sun is planning JDK 5. Due to many complaints of
Java programmers, Sun decides that a 'sort' method was needed in
java.util.List. They introduce a new

interface List2 extends List {
  public void sort(Comparator<? super E> comparator);
}

and have all JDK List-classes implement List2 instead of only List.
They encourage the use of List2 in the API Doc.

There would have been no compatibility issues at all. Programmers
would have adopted List2 whenenver they were writing new code.

Of course, if one goes down this line of thinking, one could
additionally consider language support for versioning interfaces.
Something like:

public interface List.2 extends List
{
 public void sort(Comparator<? super E> comparator);
}

// Import with version number. Only one version can be imported:
import java.util.List.2;

// Use it simply by its base name 'List':
List list = new ArrayList<String>();
list.sort(String.CASE_INSENSITIVE_ORDER);

// Or, used explicitly:
java.util.List.2 list = new ArrayList<String>();
list.sort(String.CASE_INSENSITIVE_ORDER);