Xref: utzoo comp.unix.programmer:1570 comp.lang.perl:4903 comp.std.internat:847 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!mcdphx!udc!preece From: preece@urbana.mcd.mot.com (Scott E. Preece) Newsgroups: comp.unix.programmer,comp.lang.perl,comp.std.internat Subject: Re: Tools for manipulating message catalogs Message-ID: Date: 14 Apr 91 03:38:07 GMT References: <1991Apr7.190119.24825@motcad.portal.com> <1991Apr8.191035.13836@alphalpha.com> <1991Apr10.122642.3991@dg-rtp.dg.com> Sender: news@urbana.mcd.mot.com (news) Distribution: comp Organization: Motorola MCD, Urbana Design Center Lines: 32 In-Reply-To: eliot@chutney.rtp.dg.com's message of 10 Apr 91 12:26:42 GMT Nntp-Posting-Host: etude.urbana.mcd.mot.com In article <1991Apr10.122642.3991@dg-rtp.dg.com> eliot@chutney.rtp.dg.com (Topher Eliot) writes: | To reiterate: when one is writing an application, every time one creates a | new message, it should be added to the message catalog, a message number should | be created for it, that message number should be hard-coded into the | application source code, and then it should stay that way until doomsday. | You should never WANT automatic numbering of your messages. |... | 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? --- Well, actually, I still think the use of symbolic names makes code reading easier (and code reading is critical to delivered quality). I also think that use of symbolic names is in no way counter to the principle of never changing existing message number assignments; just don't do it. Finally, an automatic tool would be useful for the important case of the first version of a program, even if subsequent versions need to maintained manually (though, actually, I think the synchronization problem would be better addressed in other ways, like keeping the source for the message catalog in a development environment that linked it to the code and generated the new catalog as part of the normal release process; I tend to think that the safest way to keep things synchronized is to always reissue them together (surely you're going to test the whole message catalog when you release a new version, anyway, right? :-)). scott -- scott preece motorola/mcg urbana design center 1101 e. university, urbana, il 61801 uucp: uunet!uiucuxc!udc!preece, arpa: preece@urbana.mcd.mot.com phone: 217-384-8589 fax: 217-384-8550