D - Interfaces with equal methods
- Riccardo De Agostini (64/64) Jul 31 2003 I tried this and it compiled and ran with not even a warning:
- Matthew Wilson (8/72) Jul 31 2003 Should be rejected, and need to be explicitly defined, perhaps in the ma...
- Riccardo De Agostini (12/16) Jul 31 2003 be
- Matthew Wilson (9/25) Jul 31 2003 DoSomething()
- Riccardo De Agostini (10/14) Aug 01 2003 I have a doubt about that. Let's take COM interfaces as an example. They...
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
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
"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 cannotbe(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
"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...DoSomething()What is certain is that, unless IA and IB are related (share a parent interface) or one inherits from the other, their respectivecannotmethods are absolutely and completely different and unrelated, andbeYes(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 anothermodule.Any suggestion?Not presently. ;) I could live with the non-decorated syntax in this case, but I agree it is inconsistentRic
Jul 31 2003
"Riccardo De Agostini" <riccardo.de.agostini email.it> "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio news:bgc56r$1td9$1 digitaldaemon.com...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 RicDo 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
Aug 01 2003