Extension methods and API evolution

[Mikael Grev]

On Dec 19, 2009, at 13:46 PM, Stefan Schulz wrote:
>  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)

Having a utility method in another class breaks the logical path the developer has to the method. The developer has the list object and want to do a sort on it. There is no logical link between static utility methods in say Collections and the objects that they can handle. The developer must know this beforehand since it can't be explored with code completion or similar IDE aids. One can help a bit by putting "soft" references to classes containing utility methods in the JavaDoc, but those are not read by most once you've learnt the API. So chances that developers familiar with the List API will go back and read that soft link in Java 7 are not very good.

So, having a method on the object itself is beneficial as it lowers the bar for finding out that it exist.

Of course one can have the static method on List itself, but that isn't very clean, is it?

Also, I'm no big fan of static imports everywhere so I would always type:

List.sort(list) 
  or
Collections.sort(list)
 and never just
sort(list)

I know many that do the same. Many, as I, only import static for enums and maybe Math.

Cheers,
Mikael