Extension methods and API evolution

[Mikael Grev]

This works for me as well. As long as there is a way to declare it that's ok.

On Dec 19, 2009, at 20:37 PM, Stefan Schulz wrote:

> Peter Levart wrote:
>> 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>  {
>> ...
> 
> While this is on declaration-site extension methods, I could think of this working for use-site extension methods as well. As IDEs need to scan and index classes anyway, this would help in finding matching use-site extensions a lot. Even better, as no String-matching is needed. For example:
> 
> package java.util;
> 
> public class Collections {
> 
>    @ExtensionMethod(List.class)
>    public static <T extends Comparable<? super T>>
>        void sort(List<T> list) {...}
> ...
> }
> 
> Stefan