Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

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
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2006-12-16 @316 Last change: 2006-12-16 @349 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.