[Issue 2538] Final method is not involved in inteface method resolution

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2538

John Hall  changed:

   What|Removed |Added

 CC||john.michael.h...@gmail.com

--- Comment #11 from John Hall  ---
This issue is discussed on the forum here:
https://forum.dlang.org/post/awkmkusrqnzdkyeyx...@forum.dlang.org

--

[Issue 2538] Final method is not involved in inteface method resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2538


ma...@pochta.ru changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Priority|P2  |P5
 Resolution|DUPLICATE   |




--- Comment #9 from ma...@pochta.ru  2009-01-22 05:03 ---
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.


-- 

[Issue 2538] Final method is not involved in inteface method resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2538


2kor...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE




--- Comment #4 from 2kor...@gmail.com  2009-01-20 02:59 ---


*** This bug has been marked as a duplicate of 2524 ***


-- 

[Issue 2538] Final method is not involved in inteface method resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2538


s...@iname.com changed:

   What|Removed |Added

 CC||s...@iname.com




--- Comment #5 from s...@iname.com  2009-01-20 12:42 ---
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


-- 

[Issue 2538] Final method is not involved in inteface method resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2538





--- Comment #6 from schvei...@yahoo.com  2009-01-20 14:53 ---
(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.


-- 

[Issue 2538] Final method is not involved in inteface method resolution

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=2538





--- Comment #7 from 2kor...@gmail.com  2009-01-20 16:57 ---
(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.


--