Cyclic definition of overriding

Alex Buckley alex.buckley at
Wed Jun 10 18:14:37 UTC 2015

On 6/9/2015 3:13 PM, Dan Smith wrote:
>> On Jun 9, 2015, at 3:38 PM, Alex Buckley <alex.buckley at>
>> wrote:
>> On 6/9/2015 2:27 PM, Dan Smith wrote:
>>>> On Jun 9, 2015, at 3:12 PM, Alex Buckley
>>>> <alex.buckley at> wrote:
>>>> On 6/9/2015 1:36 PM, Alex Buckley wrote:
>>>>> Knowing to apply rather than is extremely
>>>>> subtle. Once you do, it's plain that 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
>>>>> and 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' (, 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.


More information about the compiler-dev mailing list