Cyclic definition of overriding

[Alex Buckley]

On 6/9/2015 3:13 PM, Dan Smith wrote:
>> 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.

I think it would help to not see one example as more 
interesting/confusing than any other. An example is what it is.

In Konstantin's example, the question of whether class Test inherits 
foo() from Test1 depends on whether foo() in Test2 overrides-from-Test2 
the foo() in Test1. It's obvious that Test1 and Test2 are the sole 
determinants of the answer; class Test is irrelevant. This aligns with 
your comment that the overriding (lack of, in this case) is figured from 
the perspective of superinterface Test1, not class Test. I don't see how 
it's a problem to recognize that C, D, and D' in the fifth clause are 
all different entities.

Alex