On Wednesday, 12 March 2014 at 17:08:59 UTC, Andrei Alexandrescu
wrote:
On 3/12/14, 10:05 AM, monarch_dodra wrote:
On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei
Alexandrescu wrote:
On 3/12/14, 4:40 AM, Manu wrote:
Thank you.
There you go, it's not even hypothetical.
I think the example given works against your argument.
Andrei
How so? The example was his argument verbatim.
His argument assumed at core that the library designer knows
better than the library user what the customization points are,
and that most functions are virtual by mistake.
Andrei
There were countless arguments to demonstrate that this *is* the
case. If the developer had not considered whether the function is
safe to be virtual, it's not safe. A change request could be made
for exposing a customization point, but it is something that
needs to be done explicitly by the library designer, not just
override and hope that it works out. And of course, once you do
expose it you're stuck with it and the design that supports it
unless you want to break user code.
It would be interesting to scrape Github projects using Java
(virtual by default) and C# (final by default) and see what the
percentage of virtual functions is between each of them, as well
as see how many easily statically noticed probable bugs there are
(i.e., virtual property operating on a backing field which is
then accessed directly by a different method in the base class)
in each of them.
