On Tuesday, 4 June 2013 at 12:29:10 UTC, John Colvin wrote:
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.
For what it's worth, I did it a countless number of time in
software that is in production right now.
This virtual-by-default flexibility only exists when you're
working with classes that you understand the internals of.
No you understand its usage.
Basically, final-by-default is safer and faster,
virtual-by-default is more convenient when working with open
source libraries.
Once again the fast claim fail to address or even consider other
technique that can be used to finalize methods.
