Perl gives you at least three different ways to dynamically choose what file Perl loads:
my $module=My::File;
my $filename="My/File.pm";
do $filename;
eval `cat $filename`;
eval "require $module";
The difference between them is that
- eval qq{require $module} can only be called once per program because it is designed for loading code that might barf if you try to load it twice in a row, and of course, to avoid unnecessary recompiling of module. You have to run this code as eval string because require needs a bare word, not a quoted string, for a package name.
- do can be called multiple times, if that is what you need. Like require it uses @INC.
- eval, like do can be run multiple times. The biggest difference from do is that it can see variable values set in the calling environment. There are certain situations where that might be an advantage - for instance in a template file. However, in most cases it is likely to cause unwanted side effects. Another difference is that eval cat ... doesn't use @INC to find the file. If the file is coming from your home directory that is good. If it is meant to be stored in directory findable via @INC then you are doing things the hard way. Another disadvantage of C<eval> is that it can't spit out file names and line numbers if there is a problem reading the file
For more information see require, do, and eval.
One additional thought: If you have 40 variables that all co-vary together depending on context (development vs. production), perhaps you might consider bundling those variables in a configuration object/class. That would make any future work with these variables (in particular additional setting sets for testing purposes) much much easier to manage. 40 of anything is not a small number and is hard for the human eye to check and recheck. It is important that you use code structure/data organization as much as possible to ensure that they are set up as a group. If you decide eventually to go the object route, you might also want to consider using YAML to store the settings. The data files are very easy to write by hand (and read) and they can be loaded and dumped with ease.
Update: revised pros/cons of eval - not using @INC can sometimes be desired.
Update: added YAML suggestion
update: changed quotes to backticks on eval
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.