Comment #0 by default_357-line — 2019-06-05T21:29:02Z
The following code outputs "A":
import std.stdio;
class A {
int a;
void foo() { writefln("A"); }
}
class B : A {
int a;
override void foo() { writefln("B"); }
}
void main() { (new B).A.foo(); }
This defeats the entire point of classes. This is a side effect of https://dlang.org/spec/class.html#fields , which specifies that (new B).A.a accesses the "int a" of the base class. That's fine, but this feature should not work for virtual methods, which the subclass explicitly overrides. Only the subclass should be allowed to access super methods.
Comment #1 by b2.temp — 2019-06-06T14:38:31Z
I see this more as a feature.
It is occasionally useful and without that it would painfully hard (as seen in other languages that don't support this, some trickery with delegates and cast must be used) to call a less derived virtual method from a more derived type.
A use case is when you derive a class from a framework that you don't control and that its protection attributes or its class hierarchy have flaws. E.g: Some useful things are done in Framework.A, Only a small thing you want to avoid is done in Framework.B but your Own.C must derive from Framework.B because the rest is ok and you don't want to copy and paste 95% of Framework.B
Comment #2 by default_357-line — 2019-06-06T15:26:49Z
To me, the problem isn't that you're able to do it from Own.C, the problem is that you're able to do it from random.foo(), a function that is unrelated to the A inheritance hierarchy.
Comment #3 by b2.temp — 2019-06-06T18:45:52Z
Okay I see. Maybe that outside this should behave like a cast, which then behaves like you expect, i.e the field can be read but virtual dispatching is not shortcut.
Comment #4 by robert.schadek — 2024-12-13T19:03:47Z