Skip to main content

Java 7 - Extension methods

Posted by forax on November 29, 2007 at 3:15 AM PST

Recently,
Neals,
Peter and
Stephen
blog about extension methods.

Why i hate (yes hate) use-site extension ?

What i love (yes love) with Java is the fact that i
can take a look to a screen over one of my student
shoulder and be able to say is the snippet i see
is correct or not.


With the use-site extension
proposed by Neal,
the behavior of a code depends on some static imports
that are located in the beginning of the file.
So you can't understand a code without browsing
the entire file.

Demonstration. Do you understand this code ?

 ...
String text=...
for(int i=0;i<text.size();i++) {
   System.out.println(text.charAt(i));
}

Hum, i have forget to say that the begining of
the file contains that declaration:
import static Strings. and that
the class Strings is defined like that:

 public class Strings {
   public static int size(String s) {
     return s.trim().length();
   }
}

I'am sure i will hate that.


It will remember me the the mess of C++ member functions:
"where is the f***ing def of this method".

Furthermore, import static has already some limitations,
the code below doesn't compile. This case is currently
rare but with extension methods it will be more frequent.

  import static java.util.Arrays.*;

  public class StaticImport {
    public static void main(String[] args) {
      toString(args);
    }
  }

Why i prefer declaration-site extension methods ?

It's definitely a good property of a language
to be able to understand
a code that deals with some java.util.Lists,
just by knowing the declaration of this type.
If i don't know how to use it, i can just to
browse its code.
After that, because i have a good brain storage device,
i will be able to understand ALL codes that deals
with java.util.List.

Another proposed syntax

I think there is some problems with the
syntax proposed by Peter.

  package java.util;
  public interface List<E> … {
  …
    void sort() import static java.util.Collections.sort;
  …
  }
  1. A new syntax, again !
  2. The syntax let a developer think that this
    method can be overriden but without a modified VM
    it's not possible.

  3. The constraint on the elements of the list
    (must be comparable)
    are not visible.

Here is my proposed syntax, allow to declare static method
in interfaces (in the same time, we close
one the top 25 RFE Bug 4093687)
and add some sugar in the compiler.

  package java.util;
  public interface List<E> … {
  …
    @ExtensionMethod
    static <T extends Comparable<? super T>> void sort(List<T> list) {
      java.util.Collections.sort(list);
    }
  …
  }

Like other proposed syntax, the compiler
is modified to transform an instance call
to a static call. The following code

  List<String> list=...
  list.sort();

is rewritten to
  List<String> list=...
  List.sort(list);

@ExtensionMethod (borrowed from
Stephen blog)
like @Override is not
mandatory and tells the compiler to verify
that the first parameter of the static
method is the same type that the declaring interface.

I wait your comments,

Rémi

Related Topics >>