Extension methods and API evolution

[Stefan Schulz]

Stephen Colebourne wrote:
> 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.

Firstly, I second that the transparent use of extension methods 
introduce complications especially on the reading site. And I am still 
unconvinced about the benefit of extension methods, but maybe I missed 
the win over static utility methods, except for being able to write 
list.sort() instead of sort(list). About two years ago I wrote a blog 
post [1] about extension methods vs. method currying (or rather partial 
application, as I learned recently), where the latter would also play 
nicely with function-typed variables.

What I see with server-side extension methods, is that not only you have 
to wait for a library provider to update, fix, or extend, but that 
suddenly implementation details are going into an interface, one could 
not care less about when using the interface. To me, this seems as 
unfortunate as nested classes in interfaces.

Stefan

[1] http://jroller.com/jadda/entry/extension_methods_vs_method_currying