Extension methods and API evolution

[Mikael Grev]

Yes, I think if utility style methods are the chosen path this is a must and a good idea.
It makes the learning curve less steep.

It would be a good idea anyway, even if closures wasn't on the table.

There's some things to work out though, like how to denote the context of the utility methods.

I doubt this is something that will be considered in the scope of this spec though.

Cheers,
Mikael

On Dec 19, 2009, at 17:47 PM, Peter Levart wrote:

> On Saturday 19 December 2009 13:58:16 Mikael Grev wrote:
>> 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.
> 
> A no-language-change alternative of that might be standardizing an annotation in the JDK 
> platform that every IDE would add support for. For example:
> 
> package java.util;
> 
> @UtilityMethods({
>    "java.util.Collections#binarySearch",
>    "java.util.Collections#checkedList",
>    "java.util.Collections#fill",
>    "java.util.Collections#indexOfSubList",
>    "java.util.Collections#lastIndexOfSubList",
>    "java.util.Collections#replaceAll",
>    "java.util.Collections#reverse",
>    "java.util.Collections#rotate",
>    "java.util.Collections#shuffle",
>    "java.util.Collections#sort",
>    "java.util.Collections#swap",
>    "java.util.Collections#synchronizedList",
>    "java.util.Collections#unmodifiableList"
> })
> public interface List<E> extends Collection<E> {
> ...
> 
> 
> This way you give the author of the interface the opportunity to enumerate utility static 
> methods he/she finds most appropriate.
> 
> I know that this would satisfy me.
> 
> Peter