Extension methods and API evolution

[Stefan Schulz]

Mikael Grev wrote:
> On Dec 19, 2009, at 16:10 PM, John Nilsson wrote:
>> On Sat, Dec 19, 2009 at 1:58 PM, Mikael Grev <grev at miginfocom.com
>> <mailto:grev at miginfocom.com>> wrote:
>>
>>     So, having a method on the object itself is beneficial as it
>>     lowers the bar for finding out that it exist.
>>
>> You could add better search features to the IDE to address this. But
>> why would you? There's probably millions of methods taking i.e. List
>> as argument that has no value for the context you are in. Why would I
>> be more interested in List.sort than say, List.persist, or
>> List.sumInvoiceAmt for that matter if I have a list of File objects in
>> my current context?
>
> Exactly, that's why it's better to have methods that are generic in the
> List interface (i.e. sort with a closure as logic) and methods that are
> for a certain domain in classes, i.e. Persist#doPersistyStuff

Finding some generic methods quickly to me, as John mentioned, sounds 
like an IDE topic. For example, by indexing and providing static methods 
whose first parameter matches the variable's type. I do not see quick 
finding of (few selected) methods a real benefit wrt. all the problems 
you have with class hierarchy compatibility and such. And I don't think 
that Traits would provide a better ratio on benefit and trouble. 
Declaration-site extensions or traits only allow the class developer to 
add useful methods, which is quite limited.

I do not favour transparent use-site extensions, either, as they bear 
even more trouble. Colouring by IDEs might helpt to see the difference, 
but relying on IDEs to be able to read code properly to me is no good 
idea (while it is not that troublesome when writing code). As written in 
my blog, I am missing the more generic approach and gain, explicit 
partial application would give (and not only for the first parameter of 
a method) especially in conjunction with function-typing and method 
references.

> Writing the characters isn't what takes time so I write Collections. and
> the press ctrl+space to get the methods. After selecting the correct
> method I see no need to have the IDE remove the reference to
> Collections. It only takes additional time and makes it less clear. This
> is no biggie for me, I just think it's wrong to always show examples
> with static imports in place since that doesn't tell the whole picture.
> There are other code in that file that needs to be typed or generated by
> the IDE.

I rarely use static imports. As you say, it's really not a matter of 
characters or typing, and it makes code more readable in my eyes to say 
Collections.sort() instead of sort() only. I even don't use it on enums, 
especially with nested enums belonging to a specific outer class that 
makes the semantic clear, keeps the enum name short, and binds the enum 
to that class. So, yes, static import of extension methods would add to 
hard to read code.

Cheers,
Stefan