http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #9 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-09-08 19:31:08 PDT ---
Oh. It's totally feasible to mark all of a class' private member functions final. Personally, I always use

private:

already, so adding

final:

on top of that isn't exactly hard. However, the problem is that then everyone has to remember to do it. The default that people are generally going to want for private functions is that they be non-virtual, so if the default is virtual, that's a problem. Most private functions will then be virtual when they really should have been non-virtual, and it will cost performance - especially since you can't normally inline virtual functions.

NVI is fairly rare, I think, and that's the only reason that I'm aware of that anyone would want to have a virtual private function. And since NVI can be done with protected anyway, I really don't think that it's much of a loss to make private always non-virtual as it is now. But TDPL says that private is virtual, so either we need to decide to update TDPL's errata accordingly or to change private to virtual to bring dmd in line with TDPL. Given the relatively low benefit for a fairly high cost, I really hope that we end up going against TDPL in this case. But it's obviously not my decision.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #10 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-09-08 20:22:35 PDT ---
Isn't this what NVI is all about?

import std.stdio;

interface Foo
{
    final void callable()
    {
        impl1();
        impl2();
    }

    void impl1();
    void impl2();
}

class Bar : Foo
{
    @disable void impl1() { writeln("impl1"); }
    @disable void impl2() { writeln("impl2"); }
}

void main()
{
    Foo foo = new Bar();
    foo.callable();
}

You can't directly call impl1() from within Bar, however you can call it via the Foo interface. I think this is pretty much it, no?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #11 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-09-08 20:24:44 PDT ---
(In reply to comment #10)
> however you can call it via
> the Foo interface.

* You can also call callable() via Bar, so this works fine:

Bar bar = new Bar();
bar.callable();

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #12 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-09-08 20:40:36 PDT ---
The idea is to have a public, non-virtual function which does something before and/or after calling a private virtual function. That way, you can guarantee that certain things happen before or after the call to the private function. However IIRC, you can't actually make the private function non-callable. I forget what the details are. It was discussed in the newsgroup a while back, and Steven Schveighoffer was able to show that using private instead of public doesn't really buy you much in the way of protection - and the idiom works just fine when you use protected instead of private. It just means that there's no protection whatsoever against a derived class calling the virtual function directly. So, it's by convention at that point, but since you could get around it with private anyway (I don't remember exactly how at the moment, unfortunately), it private doesn't actually give you that guarantee anyway.

So, NVI can be done with protected just fine. It might not be quite as nice that way, but it works. On the other hand, making private virtual will result in a systematic degredation in the performance of D programs in general. It can be overcome with final, but it mean that the default is worse performance.

So, I really don't see much benefit in making private virtual. Protected will give you the main benefits of NVI just fine, whereas making private virtual gives you the slight benefit of increased cleanness in the use of NVI in some programs at the cost of performance in pretty much all programs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #13 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-10-19 15:35:23 PDT ---
What should have been done from day #1 is to implement the 'virtual' keyword and make methods non-virtual by default. It goes hand in hand with 'override'. I really don't know why virtual is on by default, maybe someone thought polymorphism would be used a lot in D but it turns out templates are much cooler to work with these days rather than OOP, just look at Phobos for example. (ok the last part is highly subjective :) )

(In reply to comment #12)
> at the cost of performance in pretty much all programs.

I wonder what would happen to performance if we suddenly switched behavior and made methods non-virtual by default (and require a 'virtual' keyword).

Of course you'd have to fix your code and add 'virtual' to base methods, but this is practically an error-free refactoring since 'override' was already required. You would get CT errors rather than weird runtime behavior (like C++03).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #14 from Jacob Carlborg <doob@me.com> 2012-10-20 06:35:47 PDT ---
(In reply to comment #13)

> Of course you'd have to fix your code and add 'virtual' to base methods, but this is practically an error-free refactoring since 'override' was already required. You would get CT errors rather than weird runtime behavior (like C++03).

It's really not. You can have a class that someone else inherits from, which you don't control.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergei.nosov@gmail.com


--- Comment #15 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-06-20 06:30:49 PDT ---
*** Issue 10422 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------