A while back, in order to improve the general behavior of my code in the Java environment, I changed a place where I was storing hot pointers to store IDs that could be used to look up the hot pointers instead. And the behavior became much better and cleaner.
Today, I realized that the behavior might be cleaner, but any "rename" operation on the objects that were referred to by the IDs was going to fail. See, when you're storing hot pointers, you can just rename the IDs that are internal to the objects that are being pointed to. When you are storing IDs, you have to find all of the objects that are storing the IDs and update them.
Phooey.
The C++ code is now updated; the Java code will follow shortly.
At least I found this myself... |
The thing is that we have a large number of objects that are keyed by the IDs and those objects simply can't be immutable because they hold our quite mutable data. When the key is renamed, we have to re-key all of the objects.
We could have a HashMap that would map keys that can be renamed to some immutable key, but this would require two lookups for each object instead of one (one to convert from the external key to the internal key; then a second lookup with the internal key). And the code would start to become impervious to debugging, because the internal keys would be essentially meaningless codes.
Heard a great talk on our internal network called "how to write a legacy horror" -- the point being that that's a good thing, because it means that your program has been around long enough, and is still useful enough, for people to be debating about whether it's better to keep maintaining it or to rewrite it.