On Tuesday, 4 June 2013 at 04:53:48 UTC, Manu 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
performance (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
final-by-default, but it will be MUCH WORSE with
virtual-by-default. I
don't want to step backwards on this front.
Even with C++ final-by-default, we've had to avoid libraries
because C++
developers can be virtual-tastic sticking it on everything.
D will magnify this issue immensely with virtual-by-default. At
least in
C++, nobody ever writes virtual on trivial accessors.
virtual accessors/properties will likely eliminate many more
libraries on
the spot for being used in high frequency situations.
Paragraph 2 destroy paragraph one.
Again, refer to Steven's pattern. Methods will almost always be
virtual in
D (because the author didn't care), until someone flags the
issue years
later... and then can it realistically be changed? Is it too
late?
Conversely, if virtual needs to be added at a later time, there
are no such
nasty side effects. It is always safe.
The solution is crystal clear to me from the beginning. You must
pay the price when you actually override a method, not when you
have the opportunity to do so.
You simply don't want to consider that option as it break your
way of doing something currently unsupported (shared object),
provide higher benefice, and do not break everybody else's code.
