Whither extension methods?

[Howard Lovatt]

I agree with this assessment that extension methods won't help for the most
interesting case of parallel processing, plus people are going to be very
confused by something that has the syntax of dynamic dispatch but
the behavior of static dispatch.

I would suggest a better alternative is a new set of Collection interfaces,
as Josh and Doug suggest, or better still Traits (personal interest in
Traits - see http://www.artima.com/weblogs/viewpost.jsp?thread=220916). Note
with Traits you can extend the present interfaces and add serial versions of
map, reduce, filter, replace, sort, etc. to the trait and then in cases for
which you control the source, e.g. JDK stuff, add efficient parallel
versions that override the serial version in the Trait.

To make the discussion concrete consider adding sort to List via a Trait:

public interface List<E> extends Collection<E> {
  void sort() { Collections.sort( this ); }
  ... // rest as before
}

Then in ArrayList you could override sort to be an efficient parallel
version:

@Override public void sort() {
  if (size() <= SMALL_PROBLEM) { List.super.sort(); return; }
  // efficient parallel code that takes advantage of internal implementation
details
}

Note Traits as proposed in the blog referenced above do not need old code to
be recompiled to use the new Trait methods; the linker will add missing
methods. There is a backward compatibility problem if an existing method in
someone's internal implementation clashes with a new Trait method. EG if
someone had an implementation of List that added "List<E> sort()" then the
linker could not add "void sort()", in such a case a linking error
would occur. This same issue occurs with extension methods.

 -- Howard.