Extension methods and API evolution

[Stephen Colebourne]

Patrick Wright wrote:
> If extension methods are declaration-site, then java.util.List and
> friends will have some methods added to them in JDK 7. These will then
> be part of the official JDK API, which means, first, you have until
> mid-2010 to get them right, second, you will never be able to change
> or remove them, and third, we will all have to wait until 201X to have
> any new(er) improved extension methods for those interfaces.
+1

> I think what no one wants are magic extensions which appear in the
> code without any choice on the part of the programmer, and are not
> obvious from the source. But if there were some way to (waving hands
> vaguely) to declare in the imports "...and extend List with
> BetterReduceMethods" then that would not be an issue.
> Perhaps I'm missing some way to reconcile this...
I wrote one option up in a blog entry at the time of the original 
discussion - 
http://www.jroller.com/scolebourne/entry/java_7_extension_methods. The 
primary concern appears to be the lack of clarity for the reader of the 
code with use site extension methods, as the method isn't in the 
interface where you'd expect it to be.

My proposed solution was to make the call site explicit that an 
extension method was being used as opposed to a regular method. Three 
possile syntaxes, there are many possible:

   list.do.sort();
   list->sort();
   list..sort();

In this way, the person reading the call site can see that the method 
call is unusual, and understand the different location of the underlying 
code.

Its certainly not as pretty as a fully integrated method call 
simulation, but it does address the concen of clarity.

I'm not saying that I'm especially in favou of the idea, as IDE colour 
coding helps these days, but it does fit your "waving hands vaguely" 
request fo a solution.

Stephen