Jump to page: 1 2
Thread overview
Why private methods cant be virtual?
Sep 21, 2020
claptrap
Sep 21, 2020
H. S. Teoh
Sep 21, 2020
Adam D. Ruppe
Sep 21, 2020
H. S. Teoh
Sep 22, 2020
claptrap
Sep 22, 2020
Daniel Kozak
Sep 22, 2020
ShadoLight
Sep 22, 2020
Daniel Kozak
Sep 23, 2020
ShadoLight
Sep 22, 2020
claptrap
Sep 22, 2020
Daniel Kozak
Sep 22, 2020
Simen Kjærås
Sep 22, 2020
claptrap
Sep 22, 2020
Arafel
Sep 22, 2020
Mike Parker
Sep 22, 2020
Daniel Kozak
September 21, 2020
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?


September 21, 2020
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
September 21, 2020
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.
September 21, 2020
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
September 21, 2020
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.
September 21, 2020
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
September 22, 2020
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.


September 22, 2020
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;
}


September 22, 2020
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


September 22, 2020
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;

« First   ‹ Prev
1 2