Summary
Extension methods would allow Java APIs to evolve without breaking backwards compatibility. Dejan Bosanac summarizes recent discussions about adding extension methods to Java 7.
Advertisement
Interfaces are one of the most important tools in managing complexity in enterprise software: By programming to a well-defined interface, developers can break complex enterprise problems into smaller, manageable components. One problem with interfaces, however, is that it's often difficult to evolve them. When an interface is widely used, making any changes to that interface would break the contract that its users rely on.
Neal Gafter addressed this problem in a recent blog post on 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...
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.Collection.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 [to] use as if they are members of the interface...
Extension methods are completely orthogonal to closures, but they enable a number of typical functional-style programming patterns to be expressed more directly in Java using extension methods that accept closures.
Gafter's proposal was followed by numerous comments, which Dejan Bosanac summarizes in Extension methods proposals:
The problem tackled by this proposal is how to extend an API (interface) with new methods without breaking existing implementations. The example used in a discussion is a List interface and the sort() method. In order to add another method to the existing interface, Java developers today create static utility functions.
There are many things about static import feature that are declared as controversial by developers, such as shadowing of imports by locally defined static methods and importing more then one static method with the same name.
The idea of extension methods for Java 7 is based on static imports and it adds another feature for such methods... The proposal is to enable usage of statically imported functions as methods of the original interface. So instead of:
sort(list)
we can use it in a more natural way
list.sort()
It is important to find a balance between the feature and how it will affect the syntax. I think it will all end up with Neal’s original proposal with note to developers "use with care".
What do you think of the idea of adding extension methods to Java? And how do you evolve interfaces in your projects?
Horrible! This will totally break the relation between the class that a method operates on (is member of) and which file it can be found in, just like in C++. There will be no simple way to find out where the broken piece of code is.
Extension methods can work for toy projects. For real-life projects with up to 50 (or so) dependencies and libraries (including the transitive ones) it will be a nightmare. How many list-sorting functions do you think will be found in such a code base? In the project I'm working on right now I already have 3 classes called StringUtil (in libraries) and 5 classes called StringUtils. What would you think the String class would look like at runtime with all those methods added to the class? How do you know which isEmpty() method is called when the class contains 4 of them?
> How do you know > which isEmpty() method is called when the class contains 4 > of them? C# solves this problem as follows: 1) Usually, the abiguity does not arise, because you import just the StringUtil you need. 2) If there are two StringUtils with join(), it is a compile time error to use extension syntax. That way, it is simple for the IDE to show which method is being used.
I am not a fan of the syntax - it looks like a dynamic dispatch call but it isn't and it also has a narrow use case (statically imported static methods). An alternative might be a with statement (like Pascal). You could use a with keyword or the symbol ->. For example suppose filter was a statically imported method that worked on a list:
list -> filter(test);
The idea of the -> is that it replaces the first argument of a call, including the hidden this. It also can be applied to a block. AddAll is a method in List already, so the following:
list -> { addAll(list2); addAll(list3); };
Puts all the lists into list. The -> operator would return as its value the result of the last operation. This would allow it to be used in a builder pattern. EG
House h = new Building() -> { add(doors); add(windows); makeHouse(); };
Re the builder pattern, there is another Java 7 proposal for this.
I like the idea of going list.sort(). Maybe I don't understand the proposal, but, if in every class where I want to go list.sort(), I have to statically import Collections, that's more effort than it is worth.
Having though long and hard for about 5 seconds, the goal should be:
every List should have sort(). I shouldn't have to say "in this code, list has sort because I did some weird import"
Therefore, List needs to have sort() added. What we need is something like (in java.util.List.java)
@defaultsto Collections.sort(this) public void sort();
or, IMO cleaner but a bit weird to have actual code in an interface
public void sort() { Collections.sort(this); }
Sun adds sort to the interface, but the @defaultsto (or the actual code) means that it is implemented, so we don't break every List in the world. (AbstractList could also have the implementation of sort, but not every List in the world extends AbstractList)
list -> synchronizedList() -> sort();
list -> { add( 1, "A" ); add( 2, "B" ); };
Home home = new Builder() -> { setWindows( windows ); setDoors( doors ); makeHome(); };
Previous Topic
