Use-cases for version ranges?

[Alex Buckley]

On 11/21/2011 1:55 PM, Eric Johnson wrote:
> Also, I'd like to point out distinctions between changing the name of a
> new version of the interface, vs. use of multiply inherited abstract
> classes (which is essentially this proposal). The proposal doesn't
> address that:
>
>     * Multiply inherited interfaces with defaults then result in
>       possible name collisions, when a client implements both
>       "interfaces" and both have defaults with the same name but
>       different implementations.

Yes, this is a problem at runtime under inconsistent separate 
compilation. Brian Goetz has been discussing it over in lambda-land.

>     * Just as with abstract classes now, if you *add* a method, it is
>       always possible that a subclass already has a method of that name.

And so while the subclass overrides the interface method (assuming the 
name, signature, and return type are all satisfactory), we're back to 
the question of behavorial compatibility: does the subclass's method 
provide a useful override of the method newly added in a supertype? I 
agree the lambda-inspired mechanisms could use some help from the module 
system.

> So, I'm still stuck at the question: what's compatibility, then? At
> least with the current model, if you change the name of the interface,
> every downstream implementation must make an explicit decision to
> embrace the new API.

No disagreement here.

Alex