> I currently work on a fairly sizable Java code base
> (approx. 220,000+ lines). I've seen two different defects
> this year caused by the signature of a virtual method
> being changed by the addition of a single parameter -
> causing the overridden methods in derived classes to be
> silently ignored by virtual calls :-) Scary stuff.

What's scary is that you didn't write the unit tests that would have found that before it became a significant problem. Test Driven Development is a cure for this kind of ill.

> When you change the signature of a method, do you remember
> to check if there are any overridden methods that might
> fall off the shelf? I don't, and I don't know anyone that
> meticulous.

Do you run all the unit tests in the system after you make that change? When you do, do they catch the error? If not, why not?

> The trouble is that unless you have enough tests, you
> won't know about the side effects of your minor signature
> changes until much later. javac certainly doesn't tell
> you!

In that case the trouble is that you don't have enough tests.

> For this horrible reason, I've been trying to get into the
> habit of using Eclipse's 'Refactor->Rename', or
> 'Refactor->Change Method Signature' actions for every
> signature change :-)

Always a good idea. Eclipse or (better yet) IntelliJ provide wonderful tools for making changes like that. And tests are the way to be sure that those changes don't harm you.

> Anders was complaining that in Java, designers don't use
> the final keyword often enough. If this is a
> problem, then why does C# have any default at all?
> Why not force the designer to declare all methods
> virtual or final ...
> The only real advantage I can see to this is performance,
> since methods are all final by default
> However, I also think that people pay too much
> attention to the performance effects of virtual vs.
> final

I agree 100% that performance is a red-herring. However, I believe there is a very strong design reason for the explicit use of virtual and final. As Hejlsberg points out, developers do a very poor job of considering the two APIs that every class exports: 1) the "client API" (i.e. all public methods), and 2) the "extension API" (i.e. all protected and virtual methods). I personally try and keep both in mind, and find that most of my methods are public final, protected final, or some flavor of abstract. Rarely do I find the case where I need to allow a sub-class to over-ride a method (and especially, a public method) on a super-class (LSP is a hash mistress!); more often I find that the extension API is more clearly defined (and controlled) using either a protected abstract or virtual protected method (in the latter case, commonly with an empty body) in a sort of Template Method pattern sense. This gives the extension developer a specific place to alter a specific behavior of the class, while allowing the super-class to protect it's client API contract.

> ... there is no particular advantage to the more explicit
> inheritance mark-up in C# to offset the annoyance of extra
> typing and spurious (unrelated to the task I'm really
> working on and trying to think about) decision-making.
> The problems it ostensibly solves don't seem to be big
> ones, they are corner-cases and the solution only
> shifts to different problems ...

I agree. For example, Hejlsberg notes that in C#, if a new method (ex. foo()) is added to a base-class when a sub-class has already used the same name, then:

>> Now there are two virtual foos. There are two VTBL
>> slots. The derived foo hides the base foo, but that's
>> fine. The base foo wasn't even there when the derived
>> foo was written, so it's not like there's anything
>> wrong with hiding this new functionality.

This is all true if the sub-class had a virtual foo(), but what if the sub-class developer had not intended his/her foo() to be part of the extension API of the class and had correctly declared it 'final'? Similarly, what if the base-class developer did not intend the new foo() method to be part of the base-class extension API, and declared it 'final'? I can't think of a reasonable way to resolve either case other than a compile/link error. Note that Hejlsberg's argument for the desirability of 'final'ity for methods which are not explicitly part of the extension API would make it more likely that one (or both) of the above cases would occur and nothing is gained by the C# way of doing things (or worse, if some language hack silently "resolves" the problem then one is left with very confusing code).

Cheers,

Geoff Sobering

> Having now done plenty of C++, Delphi, Java and C#, I'd
> say there is no particular advantage to the more explicit
> inheritance mark-up in C# to offset the annoyance of extra
> typing and spurious (unrelated to the task I'm really
> working on and trying to think about) decision-making.
> The problems it ostensibly solves don't seem to be big
> ig ones, they are corner-cases and the solution only
> shifts to different problems. Conversely, I never had
> much of a problem in other languages with
> accidentally overriding base methods -- is this
> really such a common problem that it needs to be so
> aggressively tackled? Anyone else out there have
> experiences where this was a huge problem? Would the C#
> syntax have solved it?

The people who struggle with the breakage problem are those who create reusable libraries that have wide distribution, for example, Microsoft with the .NET Framework and Sun/Java Community with the Java API. Most programmers are able to access all subclasses of their classes. That doesn't mean that it isn't a good idea. It is unlikely that this will happen to any individual, but it is likely that it will happen to some people for any Java release. The breakage can be completely avoided by expressing the programmer's intent more clearly with something like an override keyword. Whether the extra finger typing is worth solving this problem is a judgement call, but it does solve a real problem.

The point about performance is a bit fuzzier. Bjarne Stroustrup brought up the performance cost of virtual methods compared to non-virtual ones in his interview this past week. It does exist in the C++ world, but the world of VMs is a bit murkier. Most modern JVMs in long running processes can inline virtual method calls if they matter to performance, so there's no cost really in that kind of situation.

I do also agree with Anders that people don't usually really design classes to be subclassed. I think Anders' point about that fits with Josh Bloch's comments in Effective Java that we should design for inheritance or disallow it. (Note that this was also coming from someone who works with widely distributed reusable components.) I thought that Anders' most compelling argument for having non-virtual be the default was that people don't usually design for subclassing.