what is a usage pattern for "static" in an interface?

[deadalnix]

Le 03/02/2012 14:12, dennis luehring a écrit :
> Am 03.02.2012 13:55, schrieb deadalnix:
>> Le 03/02/2012 13:02, Jonathan M Davis a écrit :
>>> On Friday, February 03, 2012 09:03:21 dennis luehring wrote:
>>>> Am 03.02.2012 08:40, schrieb Jonathan M Davis:
>>>>> On Friday, February 03, 2012 08:30:31 dennis luehring wrote:
>>>>>> any idea why static could makes sense in an interface? any example?
>>>>>
>>>>> The same reason it makes sense in a class. I don't see any difference.
>>>>
>>>> that also my first thought - but why do c#, java (and c++) don't
>>>> allow it?
>>>
>>> C++ doesn't have interfaces, and C# and Java don't allow function
>>> implementations of any kind on interfaces. The same is not true for D.
>>>
>>
>> Java will allow it in its next version. This will actually be more
>> powerfull that what exists in D.
>
> Link?

You'll find that conference interesting : 
http://medianetwork.oracle.com/media/show/16999

Also, this link that explain it with code snippet. It is in french, but 
I'm sure you'll understand at least code snippet if you know java : 
http://blog.xebia.fr/2011/10/05/les-methodes-virtuelles-dextension-dans-java-8/

I think this functionnality is awesome, and D should provide a way to 
profide default implementation in interfaces if needed. The most 
important advantage is to allow an API to evolve without requiring the 
whole code using it to be rewritten.

Here is the way to go :
1/ Add the new methods in the interface, and provide default 
implementation using the old API (even if it is non optimal).
2/ Warn and then mark the old API as deprecated.
3/ When the codebase had enough time to comply with the new API, you can 
remove the old API methods.