Whenever I inherit from interface privately, compiler rises an error that inherited abstract methods are not implemented:
module test;
interface NetworkListener
{
void onConnect();
}
class SoundManager : private NetworkListener
{
private final void onConnect()
{
}
}
test.d(8): class test.SoundManager interface function NetworkListener.onConnect isn't implemented
I use private inheritance because I don't want my classes to be used as listeners by anyone but the class itself (or module it is declared in). Use case: it is an implementation detail that SoundManager is also a NetworkListener (because I allow tuning sounds from authoring tool via debug connection).
Both DMD1.x and DMD2.x are affected.
Comment #1 by 2korden — 2008-12-22T18:36:59Z
I was a bit wrong. Marking a method final is a cause of a problem, not the private inheritance itself.
Comment #2 by bugzilla — 2008-12-25T21:14:26Z
A "final private" method is not virtual, and hence won't work for an interface method. That's why the error message appears. You can make it an enhancement request if you like.
Comment #3 by 2korden — 2008-12-26T01:27:28Z
Yes, I would.
Comment #4 by 2korden — 2009-01-20T02:59:52Z
*** This bug has been marked as a duplicate of 2524 ***
Comment #5 by smjg — 2009-01-20T12:42:44Z
See issue 2524 comment 8. However, this brings us back to the problem of inheritance protection, previously brought up in issue 177 and issue 2563. We already have why it doesn't make sense for classes in D; it doesn't make sense for interfaces for a different reason. The point of private inheritance is to implement an "implemented in terms of" relationship, but interfaces contain no implementation. So the "implementing" class would gain nothing over not implementing the interface at all. I think the same would apply to protected inheritance....
Comment #6 by schveiguy — 2009-01-20T14:53:27Z
(In reply to comment #5)
> See issue 2524 comment 8. However, this brings us back to the problem of
> inheritance protection, previously brought up in issue 177 and issue 2563. We
> already have why it doesn't make sense for classes in D; it doesn't make sense
> for interfaces for a different reason. The point of private inheritance is to
> implement an "implemented in terms of" relationship, but interfaces contain no
> implementation. So the "implementing" class would gain nothing over not
> implementing the interface at all. I think the same would apply to protected
> inheritance....
>
My interpretation of the spec is that private methods are never virtual and never go into a vtable. As stated by the spec the exact set of functions that are virtual are: "All non-static non-private non-template member functions are virtual"
It is impossible for a static, template, or private function to be virtual, which means it cannot be in a vtable. final methods can be virtual (meaning they are in a vtable), they just cannot be overridden.
I would propose that it should be an error to implement an interface with private protection. It makes no sense, as an interface is used where you do not know the implementation, but a private symbol can only be used in the file it's declared in, so you *should* know the implementation by looking at the file.
Comment #7 by 2korden — 2009-01-20T16:57:48Z
(In reply to comment #6)
> I would propose that it should be an error to implement an interface with
> private protection. It makes no sense, as an interface is used where you do
> not know the implementation, but a private symbol can only be used in the file
> it's declared in, so you *should* know the implementation by looking at the
> file.
>
Maybe it doesn't make sense to you, but it certainly does to me (see my examples). I believe I've brought enough examples where private and package methods are desired to have polymorphic behavior.
Comment #8 by schveiguy — 2009-01-20T17:20:46Z
Your examples can be implemented using other means. See my responses in Bug 2524. What you are asking for is runtime protection checking.
Comment #9 by dfj1esp02 — 2009-01-22T05:03:39Z
I think, purpose of private interface implementation was well described. D is just not aimed at fanatical incapsulation and everyone failing to overincapsulate his code is advised to give it up and make everything public. This won't wreak much havoc after all :)
Marking this as low-priority RFE.
Comment #10 by dfj1esp02 — 2009-01-22T05:23:37Z
Workaround:
---
module Test;
interface NetworkListener
{
void onConnect();
}
class SoundManager : private NetworkListener
{
protected final void onConnect()
{
}
}
void main()
{
auto a=new SoundManager();
auto b=cast(NetworkListener)a;
b.onConnect();
}
---
Comment #11 by john.michael.hall — 2017-09-05T21:46:40Z