Feedback on Átila's Vision for D
Meta
jared771 at gmail.com
Sat Oct 19 23:09:11 UTC 2019
On Saturday, 19 October 2019 at 22:14:55 UTC, Meta wrote:
> On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:
>> On Friday, 18 October 2019 at 16:10:31 UTC, Atila Neves wrote:
>>
>>>
>>> I don't understand what you mean by this. What is it about
>>> OOP in D now that you can't get done without a library
>>> solution? And why are library solutions insufficient for
>>> those purposes?
>>
>> One cringeworthy problem with D's implementation of interfaces
>> and classes is how D resolves method conflicts. Conflicting
>> interface methods are silently collapsed into one
>> implementation, which seems to be by design and is definitely
>> incorrect.
>>
>> interface Display {
>> void fmt();
>> }
>>
>> interface Debug {
>> void fmt();
>> }
>>
>> class C: Display, Debug {
>> override fmt() { } // implements both interfaces
>> }
>>
>> At the very least, this should be an ambiguity error. Some
>> languages (C#, Rust) allow to disambiguate.
>
> It's not a defect. Interfaces have no state, so it doesn't
> matter which is called. Java does the same thing.
To work around this, you can use the "non-virtual interface"
pattern (there are probably other ways; this is just what comes
to mind):
import std.stdio;
interface Display
{
protected void displayFmt();
final void fmt() { displayFmt(); }
}
interface Debug
{
protected void debugFmt();
final void fmt() { debugFmt(); }
}
class Test: Display, Debug
{
override void displayFmt() { writeln("inside Display.fmt"); }
override void debugFmt() { writeln("inside Debug.fmt"); }
}
void main()
{
Display dsp = new Test();
Debug dbg = new Test();
dsp.fmt();
dbg.fmt();
}
More information about the Digitalmars-d
mailing list