On Tuesday, 4 June 2013 at 05:22:39 UTC, Andrei Alexandrescu
wrote:
Situation: I have a closed source library I want to use. I test
and find that it doesn't meet our requirements for some trivial
matter like the behavior of a few methods (super common, I
assure you).
The author is not responsive, possibly because it would be a
potentially breaking change to all the other customers of the
library, I've now wasted a month of production time in
discussions in an already tight schedule, and I begin the
process of re-inventing the wheel.
I've spent 10 years repeating this pattern. It will still be
present with virtual-by-default, but it will be MUCH WORSE with
final-by-default. I don't want to step backwards on this front.
Destroyed?
I don't buy this.
Overriding a method from a class in a closed source library is
only a sane thing to do if the docs explicitly say you can.
If the docs explicitly say you can, then one can assume that the
author will have marked it virtual.
This virtual-by-default flexibility only exists when you're
working with classes that you understand the internals of.
Consider these situations, assuming lazy but not completely
incompetent library authors:
Hidden source, virtual by default:
You can override most things, but you're playing with fire
unless you have a written promise that it's safe to do so.
Open source, virtual by default:
Once you understand the internals of a class, you can safely
override whatever you want. You are exposed to breakage due to
implementation detail, but documentation represents a promise of
sorts.
Hidden source, final by default:
You can only override what the author allows you to. This
will have at least some connection with what is safe to override.
Open source, final by default:
Once you understand the internals of a class, you can fork
the library and add virtual on the methods you need to override
that the author did not consider.*
Basically, final-by-default is safer and faster,
virtual-by-default is more convenient when working with open
source libraries.
* you might consider this an unacceptable extra burden,
especially considering distribution problems. However, I would
counter that if you're going to override a method that isn't
explicitly intended to be, you are exposing yourself to breakage
due to implementation detail and therefore it would be
distributing your own version anyway.
