Extension methods and API evolution

[Mikael Grev]

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> 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


> 
> Also, I'm no big fan of static imports everywhere so I would always type:
> Might one ask why? I know I had one issue with them being that the IDE didn't automatically add them to the import list when needed. However in Eclipse it's possible to configure it to search predefined classes for static methods to import. Which address both your autocomplete discoverability and my automatic import problem.

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.

Cheers,
Mikael

> 
> BR,
> John