On Friday, June 29, 2001, at 07:25 , Shawn Devlin wrote:
> What advantages do I gain by grouping the functions based on
> functionality? As per my response to Mr. Worrall, one of my concerns
> with placing each function call into its own module is the amount of
> memory used by the various .pm files that will be loaded numerous
> times. I can see that grouping functions based on functionality would
> reduce the number of .pm files in memory. However, if I go that route,
> then would I not be better just to leave the API as one file?
A good reason for grouping "related" functions is not so much
"functionality" as common dependencies, and ease of change management.
If everything is in one huge module, then change management become
tricky, especially with multiple developers. Giving every function its
own module avoids this, but can make tracking down dependencies tricky
(and there may be a small memory overhead for each module, but I've
never looked).
A happy medium is to group together functions that share a dependencies
on underlying database objects.
For example, if you have a family of library functions that retrieve,
insert, update, or delete user records, it might make sense to group
these together in a module. If you need to add a new field to your user
records, then you change only that module (as well as any changes
required to your scripts).
