Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ritcv!mjl From: mjl@ritcv.UUCP (Mike Lutz) Newsgroups: comp.software-eng Subject: Re: Question Re: Configuration Management Message-ID: <213@ritcv.UUCP> Date: 19 Feb 88 00:16:25 GMT References: <497@aimt.UUCP> <2640@ihlpe.ATT.COM> <188@dinl.mmc.UUCP> Reply-To: mjl@ritcv.UUCP (Michael Lutz) Organization: Rochester Institute of Technology, Rochester, NY Lines: 35 Keywords: configuration management, software design In article <188@dinl.mmc.UUCP> hull@dinl.UUCP (Jeff Hull) writes: >Why would you (ever) want to put more than one "procedure" in a file >anyway. Now that we have and similar utilities, it is very >simple to (re-)compile programs contained in many files, so why not >put one procedure in one file? The issue is one of packaging based on abstract interfaces. If I write a symbol table handler, with Initialize, Lookup, Enter, Update, and Delete operations, I want the implementation details to be hidden, especially the details of the data organization I choose. The natural package in C is one where the implementation "secrets" are kept as static global data structures (and internal support routines are static as well, to avoid name clashes with the client). To do this, of course, the visible operations must be in the same file at compile time -- and I argue that they form a unified abstraction that *should* be in one file. If you change the internal data structure details (or create alternate versions), you'll find your configuration management problems *decrease* with such packaging. And, for the person who complained about the brain damaged Unix linker and librarian: most linkers I've encountered have the same restriction. The library contains object modules, possibly with multiple entry points, and if you reference one you get them all. It's damn difficult to pull apart an object module and decide which bytes you need and which ones are extraneous. The Unix linker/librarian may not set the world on fire with it's snazzy features, but it most certainly is state of the practice. Mike Lutz ...rutgers!rochester!ritcv!mjl -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {allegra,seismo}!rochester!ritcv!mjl CSNET: mjl%rit@csnet-relay.ARPA