Automatic method overriding in sub-classes

[bitwise via Digitalmars-d]

On Tuesday, 27 October 2015 at 20:05:17 UTC, Tofu Ninja wrote:
> On Tuesday, 27 October 2015 at 14:47:03 UTC, bitwise wrote:
>> [...]
>
> Is there ever a chance the auto override definition would not 
> be available, I think the class chain all the way up to Object 
> always needs to be available at compile time to compile a 
> class, so I don't see any time an auto override definition 
> would be missing.
>
> I do like the idea of manually overriding as well if needed, 
> but with slightly different semantics than what you said.
>
> -Manually overriding an auto override with a regular method 
> would simply work and would stop the automatic overriding from 
> that class on.
>
> -Overriding an auto override with another auto override would 
> cause the new auto override to be used from that class on.
>
> -Final could still be used to stop all overriding from that 
> class on.
>
> You could even override a normal method with an auto override 
> and have no problems.

I just did a test for this. Using dmd's -H flag to generate 
header files, the bodies of member functions are removed. If you 
link a static library containing the compiled class though, 
everything will work, and you can still inherit the class.

[test.d]
module test;
import std.stdio;
class Test { void foo() { writeln("test"); } }
[/test.d]

[main.d]
module main;
import test;
import std.stdio;
class Derived : Test {
     override void foo() { writeln("derived"); }
}
void main() {
     Derived d = new Derived();
     d.foo(); // prints "derived"
}
[/main.d]

With the above two files, I did this:

dmd test.d -lib -H
rm test.d   #make sure dmd can't find body of foo()
dmd main.d test.a
./main

The above will print "derived".

I think dmd -H should definitely keep the definitions of auto 
override functions when generating headers, but in theory, 
someone could remove them, and things could still work. If 
someone received a static library and a D header file with 
missing auto override function, they wouldn't be able to inherit 
from the class, as if it were a sealed/final class. This person, 
however, could work around the problem by overriding the missing 
auto override function. I suppose this is a good reason to adopt 
the semantics you are recommending, where overriding an auto 
override function stops the automatic behaviour, or else someone 
would have to override missing auto override functions for every 
single level of inheritance after the missing auto override. I 
suppose that if someone wanted to resume the auto overrides, they 
could just override with another auto override, and call the base 
class implementation from their new override. With regards to the 
resuming of auto overriding though, I'm wondering if what I am 
proposing is possible in D. In C++, you can call any base method 
from anywhere in a class hierarchy. In D however, it doesn't seem 
to work.

[C++ ]
struct A { virtual void foo() { printf("A\n"); } };
struct B : public A { void foo() { printf("B\n"); } };
struct C : public B { void foo() { A::foo(); } };
int main() {
	C c;
	c.foo();   // prints "A"
}
[/C++]

In D however, the following will cause a compiler error:
"Error: identifier expected following '.', not 'super'"

[D]
class A { void foo() { writeln("A"); } }
class B : A { override void foo() { writeln("B"); } }
class C : B { override void foo() { super.super.foo(); } }
void main() {
     C c = new C();
     c.foo();
}
[/D]

     Bit