Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Simpler alternative to modules

by gregw (Beadle)
on Apr 17, 2001 at 15:54 UTC ( #73109=note: print w/replies, xml ) Need Help??

in reply to Creating module files from subroutines

If you don't want the trouble of converting your scripts to .pm modules, but you can share a bunch of subroutines across multiple scripts by 1) putting them in a separate file (say 2) adding a 1; to the end of the file, and 3) putting a code fragment at the beginning of scripts which would call those subroutines like
BEGIN { require "/var/www/cgi-bin/"; }
. It's not as elegant as modules and it's not particularly mod_perl friendly, but it works and is imho quicker to implement. (It is true that global variables in the two files are accessible to each other with this approach, not encapsulated and filtered through well-defined EXPORT interfaces, but you may or may not care about that depending on how your code works.) Perhaps some more experienced monk will tell you (and me) why not to do it this simple way.

Replies are listed 'Best First'.
Re (tilly) 2: Simpler alternative to modules
by tilly (Archbishop) on Apr 17, 2001 at 21:03 UTC
    If you do this you will quickly encounter the following problems:
    1. Tracking down where a routine comes from will become difficult.
    2. Scripts will reuse variables and subroutine names unbeknownst to you, and they will collide.
    3. Because of hardcoded paths it will be very hard for you to test any changes without modifying production.
    4. 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.

    1. Decide what module the routine belongs in. If the answer is none that you have, start a new module.
    2. To start a new module create a file, 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 /).
    3. Copy the subroutine into the module.
    4. Put the name of the subroutine in the @EXPORT_OK list.
    5. Comment out the original subroutine.
    6. Put use Foo qw(sub_name); back in the original script.
    7. Test. (Often the subroutine will have dependencies that also need to go into the module.)
    8. 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...)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://73109]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2017-05-26 05:05 GMT
Find Nodes?
    Voting Booth?