www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - private/package methods cannot be virtual

reply "Henning Pohl" <henning still-hidden.de> writes:
Documentation:
Member functions which are private or package are never virtual, 
and hence cannot be overridden.

I was about to write a bug report about this, because in my code 
there are tons of overridden methods which actually should be 
private/package. Can anyone tell me why this decision has been 
made? To inline them?

Do I really need to write interfaces to be able to override these 
methods?
May 06 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, May 06, 2013 14:19:12 Henning Pohl wrote:
 Documentation:
 Member functions which are private or package are never virtual,
 and hence cannot be overridden.
 
 I was about to write a bug report about this, because in my code
 there are tons of overridden methods which actually should be
 private/package. Can anyone tell me why this decision has been
 made? To inline them?
 
 Do I really need to write interfaces to be able to override these
 methods?

The decision was made to make member functions virtual by default. As soon as that function was made, there had to be a choice for every access level as to whether it would be virtual or not. public and protected obviously have to be virtual, and in general, there's no real benefit in making private virtual (and there's a definite permorfance cost to programs in general if you do), so it's non-virtual. There's a bit of disagreement with regards to package, but it was decided that it wouldn't be virtual either, as it had nothing to do with inheritance. There's actually quite a bit of disagreement on whether member functions should be virtual by default (in particular, the guys working at companies which need high performance really don't like it), but at least for the moment, that's the way it is. And in order to make private or package functions virtual, we'd need a way to do so explicitly, which we don't currently have. I'm considering creating a DIP on the matter, but I think that I'm going to wait until some of the current discussions die off; otherwise it wouldn't get the attention that it deserves (the rvalue discussion in particular is likely to be quite large). - Jonathan M Davis
May 06 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 6 May 2013 at 18:44:07 UTC, Jonathan M Davis wrote:
 On Monday, May 06, 2013 14:19:12 Henning Pohl wrote:
 Documentation:
 Member functions which are private or package are never 
 virtual,
 and hence cannot be overridden.
 
 I was about to write a bug report about this, because in my 
 code
 there are tons of overridden methods which actually should be
 private/package. Can anyone tell me why this decision has been
 made? To inline them?
 
 Do I really need to write interfaces to be able to override 
 these
 methods?

The decision was made to make member functions virtual by default. As soon as that function was made, there had to be a choice for every access level as to whether it would be virtual or not. public and protected obviously have to be virtual, and in general, there's no real benefit in making private virtual (and there's a definite permorfance cost to programs in general if you do), so it's non-virtual. There's a bit of disagreement with regards to package, but it was decided that it wouldn't be virtual either, as it had nothing to do with inheritance.

If it is private, by definition, the compiler have all override available. So it can finalize automatically.
May 06 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 6 May 2013 at 19:05:04 UTC, deadalnix wrote:
 On Monday, 6 May 2013 at 18:44:07 UTC, Jonathan M Davis wrote:
 On Monday, May 06, 2013 14:19:12 Henning Pohl wrote:
 Documentation:
 Member functions which are private or package are never 
 virtual,
 and hence cannot be overridden.
 
 I was about to write a bug report about this, because in my 
 code
 there are tons of overridden methods which actually should be
 private/package. Can anyone tell me why this decision has been
 made? To inline them?
 
 Do I really need to write interfaces to be able to override 
 these
 methods?

The decision was made to make member functions virtual by default. As soon as that function was made, there had to be a choice for every access level as to whether it would be virtual or not. public and protected obviously have to be virtual, and in general, there's no real benefit in making private virtual (and there's a definite permorfance cost to programs in general if you do), so it's non-virtual. There's a bit of disagreement with regards to package, but it was decided that it wouldn't be virtual either, as it had nothing to do with inheritance.

If it is private, by definition, the compiler have all override available. So it can finalize automatically.

This is usually true with `package` - modules that belong to the same package are usually compiled together. Ofcourse, unlike `private` it is possible to add your own module to an existing package from another library(at least namespace-wise), but I guess it's not that common.
May 06 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, May 06, 2013 21:05:03 deadalnix wrote:
 If it is private, by definition, the compiler have all override
 available. So it can finalize automatically.

Not with the current spec. As it stands, private is not hidden, merely inaccessible. So, if private were to become virtual, derived classes in other libraries could override it. That's how it works in C++. Now, quite a few of us would like private to become hidden from overload sets (which would then make it so that what you suggest could work) and make it so that nothing outside the module could override it even if it were virtual, but that's not how it is now. - Jonathan M Davis
May 06 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 6 May 2013 at 22:25:06 UTC, Jonathan M Davis wrote:
 Now, quite a few of us would like private to become hidden from 
 overload sets
 (which would then make it so that what you suggest could work) 
 and make it so
 that nothing outside the module could override it even if it 
 were virtual, but
 that's not how it is now.

I suppose you have meant override sets. I have written DIP to remove them for overload sets but AFAIR override issue was not mentioned. Probably should as it is not that much different.
May 07 2013