Marking the root of a function inheritance chain

One of the main design goals (besides C compatibility) that Bjarne Stroustrup had in the design of C++ was to make the language perform more compile-time checks whether your code is valid. While the runtime-dynamism of languages like Smalltalk and Objective C allows for much more flexible programs with a much simpler design, dynamic languages have the disadvantage that bugs in this dynamic code may go unnoticed until a user actually comes across this code in this particular situation.

I like both approaches, and try to write "dynamic" code when using Objective C, and "static" code when I use C++. But C++ has a few noticeable gaps in its static code analysis, among them the C-compatibility "feature" that it lets you assign an integer to a float (so if you divide two integers, which gives you integer division, and assign that to a float, you don't even get a warning that you should really have typecast both of them into floats before dividing to get the fractional result you wanted), and the following issue:

Recently, a colleague had to add a parameter to a method that was overridden all over the place. So, he tracked down what he thought were all instances of this method and added the parameter. However, he missed that two classes up in the hierarchy, was another implementation of this method to which he hadn't added the parameter. Since he'd added a default value to the new parameter, in some places the calls compiled to calls to the old, parameter-less root function, and in other places they called the overridden methods as intended.

Ouch.

At that moment we all realized it would be nice to have a way to indicate that a particular method is the root of the inheritance chain. Something like requiring "virtual root" to be written for the method in the root class. That way, if a method is, to the compiler, the root in an inheritance chain, but isn't marked as a root, you'd get an error message.

With that, my colleague would have immediately seen that there must be a method further up the tree that is the actual root, and he would have kept looking. In addition, if there are two roots at different levels that can be made to take the same parameters, the compiler could be made to issue a warning as in "new inheritance root hides root in superclass".

Come to think of it, just checking for such things and not having to mark a root method might already be enough to avoid bugs like this.

Anyone know of languages that have already solved this problem? I'd guess that NetBeans, Xcode 3 and other IDEs with refactoring tools make this issue moot, do they?

Reader Comments: (RSS Feed)

No comments yet

Or E-Mail Uli privately.