If you do this you will quickly encounter the following
problems:
- Tracking down where a routine comes from will become
difficult.
- Scripts will reuse variables and subroutine names
unbeknownst to you, and they will collide.
- Because of hardcoded paths it will be very hard
for you to test any changes without modifying
production.
- Without a clear division between executable and
non-executable code, people are likely to put actions
into scripts where they do not belong.
In addition the speed difference between doing the above
and doing it right with modules is insignificant if you
have ever learned to write modules.
So here is a template for stealing routines from existing
code and putting them into a procedural module.
- Decide what module the routine belongs in. If the
answer is none that you have, start a new module.
- To start a new module create a file Foo.pm, and
in it type the following template:
package Foo;
use Exporter;
@ISA = 'Exporter';
@EXPORT_OK = qw();
use strict;
# Your subs will go here.
1;
The word "Foo" must match the module name (with the usual
conversion between the package separator :: and the path /).
- Copy the subroutine into the module.
- Put the name of the subroutine in the @EXPORT_OK list.
- Comment out the original subroutine.
- Put use Foo qw(sub_name); back in the
original script.
- Test. (Often the subroutine will have dependencies
that also need to go into the module.)
- Roll out.
As for the location of modules, that is what
lib is for.
I personally have a custom configuration loader that will
(among other things) transparently do the right lib
invocations for me. In development pick up my copy of
stuff in CVS. In production pick up the production copy
of the same. The exact layout and development of that
kind of functionality is a site decision. (Having this
available has made testing and development much easier...)