On Tuesday, 4 June 2013 at 12:51:35 UTC, deadalnix wrote:
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.
What happens when the library author adds some critical
book-keeping to a method that you're overriding?
This virtual-by-default flexibility only exists when you're
working with classes that you understand the internals of.
No you understand its usage.
See my point above. you need to be certain that the exact
behaviour of the original function is not in some way critical to
the correctness of the class in general.
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.
I agree it would be nice to follow another route on this. Final
vs virtual defaults is probably an endless debate, sidestepping
it completely with a clever finalizing technique would be ideal.
