www.digitalmars.com         C & C++   DMDScript  

D - Interfaces with equal methods

reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
I tried this and it compiled and ran with not even a warning:

---cut------cut------cut------cut------cut------cut---
import c.stdio;

interface IA
{
  void DoSomething();
  void DoSomethingElse();
}

interface IB
{
  void DoSomething();
  void DoSomethingDifferent();
}

class A: IA, IB
{
  void DoSomething()
  {
    printf("Doing something..." \n);
  }

  void DoSomethingElse()
  {
    printf("Doing something else..." \n);
  }

  void DoSomethingDifferent()
  {
    printf("Doing something different..." \n);
  }
}

int main(char[][] args)
{
  A  obj = new A;
  IA a   = obj;
  IB b   = obj;

  a.DoSomething();
  a.DoSomethingElse();

  b.DoSomething();
  b.DoSomethingDifferent();

  return 0;
}

---cut------cut------cut------cut------cut------cut---

The problem is that IA and IB could have been declared by two distinct
third-party modules or libraries and the two DoSomething methods could
therefore have very different meanings. In such a case, it is my opinion
that a class should be required to implement two distinct DoSomething
methods, one for interface IA and one for IB.

I'd suggest a modification to the language specs, as follows:

interface D
{
  void foo();
}

class A: D
{
  void D.foo();
}

This would resolve ambiguities as the one exposed above and make the code
self-documenting with regard to which methods are there to implement an
interface (which acquires an importance once an interface is imported from
another module).

The dot as a separator is not a must, of course: it could as well be a
double colon, or even an at sign. I would rather avoid Kanji characters
though :-)

Walter, what do you think? Or is there a rationale behind DMD's behaviour,
which I did overlook?

Ric
Jul 31 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Should be rejected, and need to be explicitly defined, perhaps in the manner
you suggest.

What is certain is that, unless IA and IB are related (share a parent
interface) or one inherits from the other, their respective DoSomething()
methods are absolutely and completely different and unrelated, and cannot be
(implicitly) implemented with the same method in the derived class.

"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bgb2hn$p21$1 digitaldaemon.com...
 I tried this and it compiled and ran with not even a warning:

 ---cut------cut------cut------cut------cut------cut---
 import c.stdio;

 interface IA
 {
   void DoSomething();
   void DoSomethingElse();
 }

 interface IB
 {
   void DoSomething();
   void DoSomethingDifferent();
 }

 class A: IA, IB
 {
   void DoSomething()
   {
     printf("Doing something..." \n);
   }

   void DoSomethingElse()
   {
     printf("Doing something else..." \n);
   }

   void DoSomethingDifferent()
   {
     printf("Doing something different..." \n);
   }
 }

 int main(char[][] args)
 {
   A  obj = new A;
   IA a   = obj;
   IB b   = obj;

   a.DoSomething();
   a.DoSomethingElse();

   b.DoSomething();
   b.DoSomethingDifferent();

   return 0;
 }

 ---cut------cut------cut------cut------cut------cut---

 The problem is that IA and IB could have been declared by two distinct
 third-party modules or libraries and the two DoSomething methods could
 therefore have very different meanings. In such a case, it is my opinion
 that a class should be required to implement two distinct DoSomething
 methods, one for interface IA and one for IB.

 I'd suggest a modification to the language specs, as follows:

 interface D
 {
   void foo();
 }

 class A: D
 {
   void D.foo();
 }

 This would resolve ambiguities as the one exposed above and make the code
 self-documenting with regard to which methods are there to implement an
 interface (which acquires an importance once an interface is imported from
 another module).

 The dot as a separator is not a must, of course: it could as well be a
 double colon, or even an at sign. I would rather avoid Kanji characters
 though :-)

 Walter, what do you think? Or is there a rationale behind DMD's behaviour,
 which I did overlook?

 Ric

Jul 31 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgb3a7$pls$1 digitaldaemon.com...
 What is certain is that, unless IA and IB are related (share a parent
 interface) or one inherits from the other, their respective DoSomething()
 methods are absolutely and completely different and unrelated, and cannot

 (implicitly) implemented with the same method in the derived class.

Do you mean that, if they shared a parent interface and the DoSomething method belonged to it, then class A should have one and only one DoSomething? Then, following my proposal, it should be named IBase.DoSomething, where IBase is the common ancestor interface's name. This affects code readability, as it is not clear from class A's declaration that it has anything to do with IBase, provided that IA and IB come from another module. Any suggestion? Ric
Jul 31 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bgbc6l$128k$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bgb3a7$pls$1 digitaldaemon.com...
 What is certain is that, unless IA and IB are related (share a parent
 interface) or one inherits from the other, their respective


 methods are absolutely and completely different and unrelated, and


 be
 (implicitly) implemented with the same method in the derived class.

Do you mean that, if they shared a parent interface and the DoSomething method belonged to it, then class A should have one and only one DoSomething?

Yes
 Then, following my proposal, it should be named IBase.DoSomething, where
 IBase is the common ancestor interface's name. This affects code
 readability, as it is not clear from class A's declaration that it has
 anything to do with IBase, provided that IA and IB come from another

 Any suggestion?

Not presently. ;) I could live with the non-decorated syntax in this case, but I agree it is inconsistent
 Ric

Jul 31 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgc56r$1td9$1 digitaldaemon.com...
 Do you mean that, if they shared a parent interface and the DoSomething
 method belonged to it, then class A should have one and only one
 DoSomething?

Yes

I have a doubt about that. Let's take COM interfaces as an example. They all derive from IUnknown, which handles reference counting, so it is correct to have one and only one implementation of IUnknown methods in a class. But what about automation interfaces? They all derive from IDispatch to implement late binding of method calls, but shouldn't there be a separate IDispatch implementation for each automation interface a class implements, especially if two or more such interfaces have identically-named methods? A puzzled Ric
Aug 01 2003