Nothing to read here.

Thanks wfsp! I just took a look, and it seems like a great resource!


memnoch

Should I declare them as "our" variables, or should I just create a subroutine in the module and pass copies of the variables to the scripts by way of the subroutine, or would something else be better?

Either is ok, but which is best depends solely on the purpose of the modules and the data encapsulation that is required. Are the variables read-only? would setting the variables to some value have nefarious consequences? are they subject to security concerns?

There are many ways to do what you are after, e.g. have a look at the Config.pm code for an implementation of a read-only hash.

Rules of thumb:

• use lexical variables in the Module if you need to restrict the access of a variable, and dish out its content via a subroutine.
• don't reach into the caller's namespace from within a module.
• for best results, in scripts that use a module, use a package's variables with their fully qualified name rather than copying the typeglob / assigning to the current package's typeglob.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Thanks shmem! Indeed, the variables are read-only, and resetting them would not be good (though, to be sure, security is not a high concern here). I'll take a look at the link you suggested. Also, I found the following CPAN module for creating read-only scalars, arrays, hashes. Looks useful, but probably overkill for what I'm doing.

memnoch

Gloria in Excelsis Deo!

Have a look at the standard module constant, too. It's not as flexible as Readonly, but not as dangerous, either.

I wouldn't worry too much about the occasional downvote: maybe someone has clicked on the wrong button or his breakfast-egg was not boiled to perfection or whatever.

However, some may say that it is better style to update the original question-node with your comments (if they still pertain to the original question) and insights learned through studying the Monks' answers.

Simple "Thank you!" nodes are frowned upon by many as they don't add to the discussion and may elicit cries of "XP-whoring". It is perhaps better to express your gratitude for the wisdom received by a ++ vote and a private message of thanks.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Nothing to read here.

Thanks rpanman....that book looks interesting! Thanks for the tip! For those interested, a like to the above book is here.


memnoch

use strict;
use warnings;
use Common qw($common1, $common2, ..., $commonN);
[download]

Nothing to read here.

Thanks jrsimmon.....I'll probably do something like that!


memnoch

I generally steer towards using a 'Constants' package for such things.

package SUP::ServerConstants;

use strict;
use vars qw/@EXPORT @EXPORT_OK/;
require Exporter;
use base qw/ Exporter /;
use Data::Dumper;
@EXPORT = qw/SERVER_NAME MYSQL_PORT SERVER_ID/;
@EXPORT_OK = qw/HTTP_PROXY PATH_TO_BINARIES/;

use constant SERVER_NAME => 'http://FOO';
use constant MYSQL_PORT => '3308';
use constant SERVER_ID => '44';
use constant HTTP_PROXY => '';
use constant PATH_TO_BINARIES = '/var/foo';
[download]

Then to access them in your script you would have something like...

#!/usr/bin/perl -w

use strict;
use SUP::ServerConstants qw/PATH_TO_BINARIES/;

print PATH_TO_BINARIES;
[download]