Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!ubc-vision!alberta!calgary!jameson
From: jameson@calgary.UUCP (Kevin Jameson)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Keywords: configuration management, software design
Message-ID: <1356@vaxb.calgary.UUCP>
Date: 17 Feb 88 00:15:36 GMT
References: <497@aimt.UUCP> <24502@cca.CCA.COM>
Organization: U. of Calgary, Calgary, Ab.
Lines: 35

The basic problem with keeping several procedures in one physical file
is that it becomes more difficult (both conceptually and physically) to
manipulate individual procedures.  If you know that you never have
to treat a particular procedure as an individual unit, then placing
a group in one file makes more sense (eg, as with Hash_get, Hash_put, etc).
Sometimes the grouping will be forced if all related procedures require
statically allocated (ie, private) declarations.

For example, if you have one procedure per file, you can replace individual
procedures easily if need be, and are not generally penalized when you
must manipulate related groups.  The functions in the calling tree are
also more accessible (at the operating system file level vs. having to
manually search each physical file).  Translation to other languages
is made easier when you don't have to deal with many functions per 
file.  Software tools are much easier to construct for the one-proc-per-file
model too.  File i/o cost in the editor is considerably improved because
you only have to deal with small files.

We liked the one-proc/file method so much that one person in our group
wrote a a tool to combine many individual procedures into one larger
file for compilation and linking purposes (the linker could only handle
150 physical object files).  Each procedure is thus maintained in its
own file, and then it is combined with related procedures to get by
the linker restriction.

On the other hand, the one-proc/file method has some disadvantages.  The
physical file namespace can get crowded when several hundred procedures
are in the program.  The combination step takes a bit more time.  Global
name changes to related procedures take more effort.  

In our view (experience) the one-proc/file method far outweighs any
extra hassle because you can manipulate procedures at the individual
procedure level.

Kevin {ihnp4,ubc-vision}!alberta!calgary!vaxb!jameson