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