Cyclic definition of overriding

[Dan Smith]

> On Jun 9, 2015, at 3:38 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 6/9/2015 2:27 PM, Dan Smith wrote:
>>> On Jun 9, 2015, at 3:12 PM, Alex Buckley <alex.buckley at oracle.com>
>>> wrote:
>>> 
>>> On 6/9/2015 1:36 PM, Alex Buckley wrote:
>>>> Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle.
>>>> Once you do, it's plain that Test1.foo() does not
>>>> override-from-Test1 the method foo() declared in Test2, and vice
>>>> versa, thus class Test inherits both foo() methods (harmlessly).
>>>> I will add cross-refs from 8.4.8 to both 8.4.8.1 and 9.4.1.1 to
>>>> clarify.
>>> 
>>> In particular, the 8.4.8 clause:
>>> 
>>> "such that m' from D' overrides the declaration of the method m."
>>> 
>>> should read:
>>> 
>>> "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the declaration
>>> of the method m." -- note the relocation of "from D'".
>>> 
>>> (Plus class Test needs to be abstract of course.)
>> 
>> Yes, this is good.  "From D' overrides" is awkward.
>> 
>> The confusion isn't so much about Chapter 8 vs. Chapter 9 -- both
>> immediately assert that Test1 is a subclass/subinterface of Test2.
>> The problem is in recognizing that D' (Test1) is not the same as D
>> (Test), which this change makes more clear.  (Hope I'm not mixing up
>> Test1 and Test2 here, but if so, you know what I mean.)
> 
> ... that D' (Test1) is not the same as D (Test2).  (Yes, maybe D is Test1 and D' is Test2.)

Ugh, sorry.  No, I really mean "Test".  "Is not the same as C (Test)".  That is, the example ceases to be interesting/confusing once you realize that the dependency on overriding is from the perspective of the superinterface, not the class whose members are still being determined.

—Dan