www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why private methods cant be virtual?

reply claptrap <clap trap.com> writes:
Seems like a completely pointless restriction to me. I mean it 
will only affect other descendent classes declared in the same 
module, and they can access all the private members anyway, so 
it's locking the front door but leaving the back door wide open.

On the other hand if you actually want a private method to be 
virtual, you have to instead use a protected method, so it 
exposes it to be overridden elsewhere.

So it's no benefit on one hand, and net loss on the other.

Plus orthogonality, why should virtual or not be dependent on 
visibility. Two separate concepts, tied together for no benefit.

What am I missing?
Sep 21 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 21, 2020 at 11:17:13PM +0000, claptrap via Digitalmars-d-learn
wrote:

 Seems like a completely pointless restriction to me.


[...]

It looks like a bug to me.  Please file one if there isn't already one:

	https://issues.dlang.org/


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases. 
He/She has prejudices. -- Gene Wirchenko
Sep 21 2020
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 September 2020 at 23:30:30 UTC, H. S. Teoh wrote:

 It looks like a bug to me.


No, it is by design:

https://dlang.org/spec/function.html#virtual-functions

see point 2.
Sep 21 2020
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/21/20 7:30 PM, H. S. Teoh wrote:

 On Mon, Sep 21, 2020 at 11:17:13PM +0000, claptrap via Digitalmars-d-learn
wrote:

 Seems like a completely pointless restriction to me.


 [...]
 
 It looks like a bug to me.  Please file one if there isn't already one:
 
 	https://issues.dlang.org/
 
 
 T
 


No, it's not a bug. It's intentional.

private and package functions are final, and we aren't going to change 
that now, even if it makes sense to make them virtual.

-Steve
Sep 21 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 21, 2020 at 07:43:30PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]

 No, it's not a bug. It's intentional.
 
 private and package functions are final, and we aren't going to change
 that now, even if it makes sense to make them virtual.


[...]

Whoa.  But why??  What's the reasoning behind private being non-virtual?


T

-- 
What doesn't kill me makes me stranger.
Sep 21 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/21/20 7:52 PM, H. S. Teoh wrote:

 On Mon, Sep 21, 2020 at 07:43:30PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
 [...]

 No, it's not a bug. It's intentional.

 private and package functions are final, and we aren't going to change
 that now, even if it makes sense to make them virtual.


 [...]
 
 Whoa.  But why??  What's the reasoning behind private being non-virtual?


You'd have to confirm with Walter. This is a relic from D1. I think it 
has something to do with the expectation of whether a private function 
makes sense to override. The use case is pretty narrow -- allow 
overriding only within the current package/module. But I can see the use 
case being valid.

However, changing it now means a slew of code becomes virtual that is 
currently not virtual. This could be a problem for existing code.

If we ever got a virtual keyword, then it might be possible to allow 
them to become virtual if you opt-in. But I don't see it happening 
without that.

If you do a search on the general forum, you will find a few 
conversations about this in the way past. It's been discussed, but never 
changed.

-Steve
Sep 21 2020
parent reply claptrap <clap trap.com> writes:
On Tuesday, 22 September 2020 at 00:46:02 UTC, Steven 
Schveighoffer wrote:

 On 9/21/20 7:52 PM, H. S. Teoh wrote:

 On Mon, Sep 21, 2020 at 07:43:30PM -0400, Steven Schveighoffer 
 via Digitalmars-d-learn wrote:
 [...]

 No, it's not a bug. It's intentional.

 private and package functions are final, and we aren't going 
 to change
 that now, even if it makes sense to make them virtual.


 [...]
 
 Whoa.  But why??  What's the reasoning behind private being 
 non-virtual?


 You'd have to confirm with Walter. This is a relic from D1. I 
 think it has something to do with the expectation of whether a 
 private function makes sense to override. The use case is 
 pretty narrow -- allow overriding only within the current 
 package/module. But I can see the use case being valid.

 However, changing it now means a slew of code becomes virtual 
 that is currently not virtual. This could be a problem for 
 existing code.

 If we ever got a virtual keyword, then it might be possible to 
 allow them to become virtual if you opt-in. But I don't see it 
 happening without that.


"All public and protected member functions which are non-static 
and are not templatized are virtual ***unless the compiler can 
determine that they will never be overridden***"

IE the compiler is supposed to make methods non-virtual 
automatically, it should be easy to do for private as all the 
relevant info be in the one compilation unit.

Then there's this gem from the docs..

"Functions marked as final may not be overridden in a derived 
class, unless they are also private"

So final private functions can be overriden? It seems not, but 
the sentence is definitely confusing if not just plain wrong.
Sep 22 2020
next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Sep 22, 2020 at 12:23 PM Daniel Kozak <kozzi11 gmail.com> wrote:


 ...
 void main(string[] args)
 {
 B b = new B;
 b.overrideFun;
 }


You can have A and B in one module too of course
Sep 22 2020
prev sibling next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Sep 22, 2020 at 11:06 AM claptrap via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 "Functions marked as final may not be overridden in a derived
 class, unless they are also private"

 So final private functions can be overriden? It seems not, but
 the sentence is definitely confusing if not just plain wrong.

 Yes they can, if you have class A in one module and class B in another


module this will work:

//a.d
class A
{
private final void overrideFun()
{
import std.stdio : writeln;
writeln("A::overrideFun");
}
}

//b.d
import a;
class B : A
{
void overrideFun()
{
import std.stdio : writeln;
writeln("B::overrideFun");
}
}

// main.d
import b;

void main(string[] args)
{
B b = new B;
b.overrideFun;
}
Sep 22 2020
next sibling parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
On Tuesday, 22 September 2020 at 10:23:08 UTC, Daniel Kozak wrote:

 On Tue, Sep 22, 2020 at 11:06 AM claptrap via 
 Digitalmars-d-learn < digitalmars-d-learn puremagic.com> wrote:


 "Functions marked as final may not be overridden in a derived 
 class, unless they are also private"

 So final private functions can be overriden? It seems not, but 
 the sentence is definitely confusing if not just plain wrong.

 Yes they can, if you have class A in one module and class B in 
 another


 module this will work:

 //a.d
 class A
 {
 private final void overrideFun()
 {
 import std.stdio : writeln;
 writeln("A::overrideFun");
 }
 }

 //b.d
 import a;
 class B : A
 {
 void overrideFun()
 {
 import std.stdio : writeln;
 writeln("B::overrideFun");
 }
 }

 // main.d
 import b;

 void main(string[] args)
 {
 B b = new B;
 b.overrideFun;
 }


This is not really "overriding", it is more akin to 
"overloading". It is also not polymorphic i.e. this will call  
A::overrideFun.

A b = new B;
b.overrideFun;
Sep 22 2020
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Sep 22, 2020 at 1:30 PM ShadoLight via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 This is not really "overriding", it is more akin to "overloading"


No it is not  overloading, overloading is when you have more methods with
same name and differents params. It is overriding


 It is also not polymorphic


I did not say otherwise :-)
Sep 22 2020
parent ShadoLight <ettienne.gilbert gmail.com> writes:
On Tuesday, 22 September 2020 at 11:39:31 UTC, Daniel Kozak wrote:

 On Tue, Sep 22, 2020 at 1:30 PM ShadoLight via 
 Digitalmars-d-learn < digitalmars-d-learn puremagic.com> wrote:


 This is not really "overriding", it is more akin to 
 "overloading"


 No it is not  overloading, overloading is when you have more 
 methods with same name and differents params. It is overriding


Which is why I said it is "is more akin to "overloading"" i.e. 
what I meant is that the behaviour is kind-of "similar" to 
overloading in your example.  I did not mean it was classical 
overloading.

The thing is that, if the base class method is non-virtual, 
calling it "overriding" is confusing and somewhat misleading - 
all the derived class does is hide (or "shadow" if you like) the 
base class method.


 It is also not polymorphic


 I did not say otherwise :-)


Granted, but your example is confusing in the light that the OP 
specially asked about virtual and polymorphic behaviour.
Sep 23 2020
prev sibling parent reply claptrap <clap trap.com> writes:
On Tuesday, 22 September 2020 at 10:23:08 UTC, Daniel Kozak wrote:

 On Tue, Sep 22, 2020 at 11:06 AM claptrap via 
 Digitalmars-d-learn < digitalmars-d-learn puremagic.com> wrote:


 "Functions marked as final may not be overridden in a derived 
 class, unless they are also private"

 So final private functions can be overriden? It seems not, but 
 the sentence is definitely confusing if not just plain wrong.

 Yes they can, if you have class A in one module and class B in 
 another


 module this will work:

 //a.d
 class A
 {
 private final void overrideFun()
 {
 import std.stdio : writeln;
 writeln("A::overrideFun");
 }
 }

 //b.d
 import a;
 class B : A
 {
 void overrideFun()
 {
 import std.stdio : writeln;
 writeln("B::overrideFun");
 }
 }

 // main.d
 import b;

 void main(string[] args)
 {
 B b = new B;
 b.overrideFun;
 }


The thread title is...

"Why private methods cant be virtual?"

IE Not...

"how do I override private functions in a non-polymorphic manner."

And what you suggest wont work because I was asking about virtual 
functions, so I specifically want polymorphism. And FWIW it's no 
big deal I can just use protected, i wasn't looking for a 
solution, I was looking for an explanation as to why it was done 
that way. But apparently there is none.
Sep 22 2020
next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Sep 22, 2020 at 3:05 PM claptrap via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 The thread title is...

 "Why private methods cant be virtual?"

 IE Not...

 "how do I override private functions in a non-polymorphic manner."

 And what you suggest wont work because I was asking about virtual
 functions, so I specifically want polymorphism. And FWIW it's no
 big deal I can just use protected, i wasn't looking for a
 solution, I was looking for an explanation as to why it was done
 that way. But apparently there is none.


And I did not try to show solution. It was just an answer to this part of
your response:

So final private functions can be overriden? It seems not, but
the sentence is definitely confusing if not just plain wrong.

So the reason why there is this:

"Functions marked as final may not be overridden in a derived
 class, unless they are also private"

Is because with private methods final keyword has no meaning.

And there is a reason "Why private methods cant be virtual?".
It is because it would break existing code. And because  private methods
are final it makes them fast.
 And yes compiler probably could findout that method could be made
non-virtual but I am not sure how easy is this and how it would slow down
compilation times
Sep 22 2020
next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 22 September 2020 at 13:19:10 UTC, Daniel Kozak wrote:

 So final private functions can be overriden? It seems not, but 
 the sentence is definitely confusing if not just plain wrong.


Yeah. I've seen this called hiding, shadowing and overwriting 
earlier, but never overriding - that's always been reserved for 
the polymorphic kind.

I'd argue the documentation should use one of those other terms.



  And yes compiler probably could findout that method could be 
 made
 non-virtual but I am not sure how easy is this and how it would 
 slow down
 compilation times


Steve showed a few posts up one example that would make it 
basically impossible. Other language features make it even worse:

     class A { private void fun() {} }
     class B(string s) : A { mixin(s); }

--
   Simen
Sep 22 2020
prev sibling parent claptrap <clap trap.com> writes:
On Tuesday, 22 September 2020 at 13:19:10 UTC, Daniel Kozak wrote:

 On Tue, Sep 22, 2020 at 3:05 PM claptrap via 
 Digitalmars-d-learn < digitalmars-d-learn puremagic.com> wrote:


 The thread title is...

 "Why private methods cant be virtual?"

 IE Not...

 "how do I override private functions in a non-polymorphic 
 manner."

 And what you suggest wont work because I was asking about 
 virtual functions, so I specifically want polymorphism. And 
 FWIW it's no big deal I can just use protected, i wasn't 
 looking for a solution, I was looking for an explanation as to 
 why it was done that way. But apparently there is none.


 And I did not try to show solution. It was just an answer to 
 this part of your response:

 So final private functions can be overriden? It seems not, but 
 the sentence is definitely confusing if not just plain wrong.

 So the reason why there is this:

 "Functions marked as final may not be overridden in a derived
  class, unless they are also private"

 Is because with private methods final keyword has no meaning.


Its not that final has no meaning for private methods, but that 
final has no meaning for non-virtual methods, and private methods 
happen to be non-virtual. IE. It's a side effect of making 
private methods non-virtual, not a direct effect of them being 
private.

And lets be honest, overriding a virtual method is a different 
thing to "overriding" or rather hiding a non virtual one.

It's mistake to use the same terminology for both cases.



 And there is a reason "Why private methods cant be virtual?".
 It is because it would break existing code.


Why would it break existing code?



 And because  private methods are final it makes them fast.
  And yes compiler probably could findout that method could be 
 made non-virtual but I am not sure how easy is this and how it 
 would slow down compilation times


Testing it out on compiler explorer it seems neither LDC or DMD 
de-virtualize a simple case, a class with one method, no decedent 
class,

So maybe the docs shouldn't say that it does so.
Sep 22 2020
prev sibling parent reply Arafel <er.krali gmail.com> writes:
On 22/9/20 15:04, claptrap wrote:

 
 The thread title is...
 
 "Why private methods cant be virtual?"
 
 IE Not...
 
 "how do I override private functions in a non-polymorphic manner."
 
 And what you suggest wont work because I was asking about virtual 
 functions, so I specifically want polymorphism. And FWIW it's no big 
 deal I can just use protected, i wasn't looking for a solution, I was 
 looking for an explanation as to why it was done that way. But 
 apparently there is none.
 
 
 


TL;DR: Wouldn't `package` [1] visibility probably be a better option in 
any case?

Long Answer:

My guess is that this was taken from Java, as in fact most of the D 
class system seems to be (see `synchronized`, reference semantics, etc). 
There it makes sense, because there is only one class per compilation 
unit, so the `private` members are in effect hidden from any child 
classes and it wouldn't make sense to override them.

The different (and to me still confusing, but I understand the reasoning 
behind it) factor in D is that the encapsulation unit is the module, not 
the class. Hence, you can have multiple classes in the same module 
inheriting from each other.

These classes can then access the private members of the parent, but not 
override it, which as you say is somewhat strange.

I personally would rather have the class as the encapsulation unit for 
classes, and then this point would be moot, but I come mostly from Java, 
so that might just be my bias, and, as I said, I understand there are 
also good reasons to keeps the module as the common encapsulation unit.

Still, I think that when you design a class, if you declare something as 
`private` means that it's an internal implementation detail that you 
don't want to expose, much less any child class to override.

In fact, to allow only the classes in the same module to override a 
private method looks to me like code smell. You likely have good reasons 
to do it, but, even if it were possible, I would probably try to do it 
in a way where the intent is clearer, either through `protected` or 
`package` visibility... the latter has the added benefit that you can 
split the module later if needed.

A.

[1]: https://dlang.org/spec/attribute.html#visibility_attributes
Sep 22 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/22/20 10:11 AM, Arafel wrote:


 My guess is that this was taken from Java, as in fact most of the D 
 class system seems to be (see `synchronized`, reference semantics, etc). 
 There it makes sense, because there is only one class per compilation 
 unit, so the `private` members are in effect hidden from any child 
 classes and it wouldn't make sense to override them.


This is a very good guess. Specifically, I think classes (and the 
mechanisms for inner classes and anonymous classes) were added to D1 to 
allow porting of JWT to D.

-Steve
Sep 22 2020
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 22 September 2020 at 14:19:09 UTC, Steven 
Schveighoffer wrote:

 On 9/22/20 10:11 AM, Arafel wrote:



 This is a very good guess. Specifically, I think classes (and 
 the mechanisms for inner classes and anonymous classes) were 
 added to D1 to allow porting of JWT to D.


Classes existed long before then. But yeah, the inner classes and 
anonymous classes were added for DWT, IIRC.
Sep 22 2020
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/22/20 5:00 AM, claptrap wrote:

 IE the compiler is supposed to make methods non-virtual automatically, 
 it should be easy to do for private as all the relevant info be in the 
 one compilation unit.



class A
{
   private void foo() {}
}

class B(T) : A
{
    static if(T.stringof == "BlahBlahBlah") private override foo() {}
}

-Steve
Sep 22 2020