Broken?

[Kapps]

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.