You see, right now, we key the account rows in our system using a 32-bit integer key which we break down into three segments and display as a string separated by periods. In the new, improved system that I'm working up, we'll key the account rows with an arbitrary string, but it can still have up to three segments which mean pretty much what the old segments meant.
An old account when displayed might look like "1000.00.000" or "2000.01.100". If you specified the third segment (for subaccounts) as non-zero, you had to specify the second segment (for related accounts) even if it was zero. If the last two segments were all zeroes, you didn't need to display them at all, so "1000.00.000" was the same as "1000".
The problem is that the old system -- as you see above -- required you to stick "00" into the middle segment if you wanted to use the last segment, which specifies our subaccounts. Not all accounts in the system will have a middle segment, but they may still need to have subaccounts.
And I think that constructs like "1000..000" are plug ugly. Nor do I want to force the user to put some arbitrary "null" character in between the two periods. And if I don't do that (require two periods if a subaccount is specified), then I can't figure out in an arbitrary string whether the user intended to specify a subaccount segment or a middle segment.
So I've decided that the format of names will use a period to separate the middle segment and a colon to separate the subaccount segment. This way, when I look at "1000.00", I can uniquely say that the prefix is "1000" and the middle segment is "00" and there's no subaccount segment; while "1000:000" says that the prefix is "1000", there's no middle segment, and the subaccount segment is "000".
That's what you'll get on conversion, anyway. New templates will likely use real names rather than numbers.
And I'm hoping that our users will learn to like "1000.00:000". :)
The Plan B part of all this is that I kept trying to figure out how to support and correctly parse an account name that contained one period into three parts, one of which was blank, if only I knew which one. I had an ugly little scheme that involved storing IDs with three separate strings which I spent several days mucking around with.
All of that code is now being pulled out and replaced.
And I'm staring at about 450 compilation errors again, which is pretty much where I was when I shifted to Plan B.