On Tuesday, 4 June 2013 at 05:58:32 UTC, Andrei Alexandrescu
wrote:
On 6/4/13 1:16 AM, Manu wrote:
But unlike the first situation, this is a breaking change. If
you are
not the only user of your library, then this can't be done
safely.
Same fallacy all over again, for the third time in this thread.
You keep on going about "breaking change" without recognizing
that the now broken code was happily taking advantage of the
very flexibility that you argue was useless and needed fixing.
I believe Manu's point is that the original flexibility was a
mistake: the author of the library never intended for the method
to be overridden; it was an accident of virtual-by-default. The
fact that overriding methods on the class works for a client is
just a coincidence, and could be dangerous.
The problem occurs when, later, the author profiles and notices
that the virtual methods are causing performance issues, or
notices that the method should not have been virtual (perhaps he
relies on the base behaviour's semantics). Marking it final now
would be a breaking change for the client relying on the
accidental virtual functions.
If things were final by default, then you would have to opt-in to
virtual, so it is unlikely that you will mark a method virtual by
accident. There is no breakage changing a method from final to
virtual.
FWIW: I think making method final by default now would cause too
much breakage, but I do agree with Manu that it would have been a
better choice in the beginning.
