Re: gcj/298

[Bryce McKinlay <bryce at albatross dot co dot nz>]

The following reply was made to PR gcj/298; it has been noted by GNATS.

From: Bryce McKinlay <bryce@albatross.co.nz>
To: apbianco@redhat.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/298
Date: Wed, 01 Nov 2000 14:47:05 +1300

 Alexandre Petit-Bianco wrote:
 
 > This is an interesting case. A first search produces two candidates:
 > List.foo and LinkedList$Entry.foo. In the search for the most specific
 > method, we find that their arguments are compatibles. So with the
 > candidate we should retain, we try:
 >
 >   valid_method_invocation_conversion_p (List, LinkedList$Entry)
 >
 > Which makes us call
 >
 >   valid_ref_assignconv_cast_p (LinkedList$Entry, List, 0)
 >
 > And we find that we can't assign LinkedList$Entry to List so we
 > propagate false as a return value in the call chain and we don't mark
 > our candidate (LinkedList$Entry.foo) to be more specific than what
 > we've seen so far. Eventually we fail at finding one and we bail.
 >
 > Jikes and Javac found that LinkedList$Entry.foo is more specific than
 > List.foo. I don't know what criterion they used.
 
 Simple - the method in the innermost context is always the most specific!
 
 May I refer you to PR 322, which is somewhat related to this.
 
 Method resolution should always stop at the first nesting level in which
 a matching method name (not signature) is found. eg: if I change the
 example to
 
 class List {
         void foo (int i) {}    <---
 }
 class LinkedList extends List {
     class Entry {
         void x () { foo (1); }   <---
         public void foo () {}
     }
 }
 
 then it should not compile, because only Entry.foo() is ever considered
 by the compiler, and its signature does not match. When a method's
 signature matches exactly a method declared in an outer context,
 the innermost definition is always used, unless the call is explicitly
 qualified with "Outerclass.this".
 
 However, outer contexts still need to be checked, because in the case
 where an intermediate context inherits a method that hides a method in an
 outer context, javac throws an error. eg:
 
 class A
 {
   void a(int i)  { }
 }
 
 class O
 {
   void a(int i, int k) {}
 
   class B extends A
   {
     class C
     {
       void b()
       {
  a(1);
       }
     }
   }
 }
 
 $ javac Patch.java
 Patch.java:16: a(int) is inherited from A and hides method in outer class
 O.  An explicit 'this' qualifier must be used to select the desired
 instance.
         a(1);
         ^
 1 error
 
 Note that it does this even though the signatures of the two a() methods
 do not match.
 
 regards
 
   [ bryce ]