Formal model for defender method resolution

[Ali Ebrahimi]

Hi,


On Wed, Feb 2, 2011 at 10:00 AM, Neal Gafter <neal at gafter.com> wrote:

> On Tue, Feb 1, 2011 at 9:48 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> >  I see your point: there is a unique, non-overridden concrete
> >> implementation here, as in the previous example.
> >>
> >> In both this and the previous example, any problem arises only in the
> >> context of a particular concrete class.  Either the class has a unique
> >> overrider for each abstract method it inherits, or it does not (and is
> >> rejected).  Why should we should reject interfaces, which can't
> >> generally be instantiated in isolation anyway?  I think the primary
> >> reason (if there is one) is that there are defaults in the hierarchy
> >> that can't be "used" by a class because of ambiguity, so the defaults
> >> dont do the clients any good.  I think you're thinking that ought to
> >> be an error we want to diagnose when the interface is compiled.  Is
> >> that right?
> >>
> ...

*class A<T> {
>  public T m() { ... }
>  public abstract String m();
> }
> class D extends A<String> {
> }
> *
>
this code does not compile.

m() is already defined in A.

>
>
>
>