Xref: utzoo comp.unix.programmer:1549 comp.lang.perl:4879 comp.std.internat:833 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.unix.programmer,comp.lang.perl,comp.std.internat Subject: Re: Tools for manipulating message catalogs Message-ID: <1991Apr11.084924.1951@alphalpha.com> Date: 11 Apr 91 08:49:24 GMT References: <1991Apr7.190119.24825@motcad.portal.com> <1991Apr8.191035.13836@alphalpha.com> <1991Apr10.122642.3991@dg-rtp.dg.com> Organization: asi Lines: 51 In article <1991Apr10.122642.3991@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes: >Serbo-Croation is more of a challenge). Depending on how you distribute them >to customers, they may or may not arrive in sync with the new executable >code. Customers may or may not load all the new message catalogs. On and on. >All in all, keeping message catalogs synchronized with programs that use >them is a real bitch. ... >Have I made my point clear? Would anyone care to point out flaws in my logic? >Does anyone still think that a tool to create a .h file out of a message >catalog is useful? Absolutely. First of all you're trying to protect me from myself. I'd rather establish conventions to do that than require it in the code. While you could argue that the code readability doesn't change, your mechanism makes it more likely that people will enter the wrong number in the code, and thus get the wrong error message. Furthermore it makes it impossible to reorganize the message catalog. I have some very large catalogs where I like to organize things (like having all of the "File" menu items in one place). If the numbers are hardcoded into my program I can never do this, even when I know it's safe. So the readability of the message catalog gets much worse over time. I'm clearly on the other side of the fence from you on this one. Not only does my gencat create .h files, it also allows me to create a catalog that doesn't specify any numbers at all - it generates them automatically. I agree that there is potential for screw ups here, particularly since people get real annoyed everytime they modify the catalog, get new header files and have to rebuild (that's the reason I make my gencat compare the new and old header files and only update if the actual values/names have changed). I don't think that the danger here, however outweighs the advantages. In addition there is a way to, if not prevent the problem, at least spot it. Simply have a convention, as a user of message catalogs, that messageId #1 is a version number. Every time you make an incompatible change to the catalog, change the version number. Have your application check the version number and complain if it doesn't match. All that said, I don't think there is so much a "flaw" in your arguments, as a matter of preference and tradeoffs. Even if gencat does create header files, you are certainly under no obligation to use them, so it seems to me we can both coexist happily (so long as I never have to use any of your code :-). -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.