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 :-)

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

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.

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

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

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

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

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.

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.

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.