Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
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
Re: Why private methods cant be virtual?
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
Re: Why private methods cant be virtual?
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
Re: Why private methods cant be virtual?
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
Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
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
Re: Why private methods cant be virtual?
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 :-)
Re: Why private methods cant be virtual?
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;
Re: Why private methods cant be virtual?
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;
}
Re: Why private methods cant be virtual?
On Tue, Sep 22, 2020 at 12:23 PM Daniel Kozak wrote:
> ...
> void main(string[] args)
> {
> B b = new B;
> b.overrideFun;
> }
>
You can have A and B in one module too of course
Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
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
Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
On 9/21/20 7:30 PM, H. S. Teoh wrote: On Mon, Sep 21, 2020 at 11:17:13PM +, 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
Re: Why private methods cant be virtual?
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.
Re: Why private methods cant be virtual?
On Mon, Sep 21, 2020 at 11:17:13PM +, 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
Why private methods cant be virtual?
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?
