Extension methods and API evolution

[Rémi Forax]

Le 19/12/2009 21:10, Mikael Grev a écrit :
> This works for me as well. As long as there is a way to declare it that's ok.
>    

And the compiler is supposed to crawle the workspace (and the universe)
to find such annotation ?

cheers,
Rémi

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