Method Bodies in Interfaces -- Why Not?

[Neal Gafter]

On Sat, Mar 14, 2009 at 1:32 PM, Neal Gafter <neal at gafter.com> wrote:
> I think adding extension methods as C# does is both simpler and more
> powerful than adding method bodies to an interface.  See
> http://www.javac.info/ExtensionMethods.html for a very brief glossy.
> I do not plan to submit a proposal for this.

To keep the discussion in one place, I've included it below:

Add support for Extension Methods.

Once an API has been published, you can't add methods to it without
breaking backward compatibility. That's because implementations of the
old version of the interface don't provide an implementation of any
new methods. You can use abstract classes instead of interfaces, and
only add concrete methods in the future. Unfortunately, that limits
you to single inheritance.

One way API designers work around this limitation is to add new
functionality to an interface by writing static utility functions. For
example, java.util.Collections.sort acts as an extension of
java.util.List. But such methods are less convenient to use, and code
written using them is more difficult to read.

Extension methods enable programmers to provide additional methods
that clients of an interface can elect use as if they are members of
the interface. Todd Millstein's Expanders
<http://www.cs.ucla.edu/~todd/research/expanders/> are the most
full-featured version of this feature. The simplest version of this
feature that I advocate would be to enable statically-imported methods
to be used as if members of their first argument type. For example:

    import static java.util.Collections.sort;
    ...
    List<String> list = ...;
    list.sort();

One of the biggest advantages of extension methods is that they enable
more flexible extension of the language moving forward. For example,
suppose a new Automated Resource Management statement were defined in
terms of invoking an acquire() method, and then later invoking a
release() method on the result of the earlier acquire(). Clearly
existing APIs such as Closeable do not implement this protocol, but by
providing static factory methods they could be made to act as if they
do. Such a statement could then be easily retrofitted onto other
resource APIs, such as java.util.concurrent.locks.Lock (an interface),
simply by providing extension methods. This retrofitting introduces no
breaking changes, since the underlying APIs are not changed.