Some work I did on a potential open source project turned up a problem in the BetterListStr class I posted a while back. Turns out there's a flaw in my "double-indexing" technique. Why didn't it crop up before? Because I used the class in a new way. Or, put another way, there wasn't a test plan or a unit test for the class. It was just a little class after all...
But even little classes can harbor big bugs as I have just managed to demonstrate. What happened here? My BetterListStr class keeps a second index to allow the list to be traversed without knowing the keys in advance. This has been in production use since July 2006. It works well and continues to work well because it doesn't ever try to update an item that's been put in the list. Updating the "normal" list index is no problem; That is part and parcel of what lists are for. Updating the second index is where things get break down. As written, there's no way to determine the second (numeric) index given the first index. Attempts to get at any updated data stored via the second index will get the original data.
I haven't fixed this in the class yet. I'm still considering the best way. Another list in the class that stores the index of the first key might work.
Technorati: None