perl-ish global variable?

I

ivowel

what is the perl-ish way to define a global variable that is used by
many modules (e.g., the location of all databases, or of a particular
server)? Clearly, I want to define it only once, and have it be
accessible everywhere.

my first inclination was to put it into base.pm and use the Exporter to
just export it. its a bit of a pain, especially if the program itself
calls other modules, all of which have to import the base module
themselves, too. But it is doable.

now, looking at Damien's perl6's suggested replacement for Exporter, I
did not find a way to export scalars. it just seems to export subs.
so maybe the export mechanism ain't it.

so, what is the perlish way to do this?

related question---if I want to break a program into a couple of
different files, what is the recommended way of doing this? is it
stuffing different routines into different modules? I am thinking of
something like the numerical recipees version, where I have hundreds of
subroutines. there, they put every sub into its own equal-named file.
of course, I may need 'em all in my program.

sincerely,

/iaw
 
J

John Bokma

what is the perl-ish way to define a global variable that is used by
many modules (e.g., the location of all databases, or of a particular
server)? Clearly, I want to define it only once, and have it be
accessible everywhere.

my first inclination was to put it into base.pm and use the Exporter to
just export it. its a bit of a pain, especially if the program itself
calls other modules, all of which have to import the base module
themselves, too. But it is doable.

now, looking at Damien's perl6's suggested replacement for Exporter, I
did not find a way to export scalars. it just seems to export subs.
so maybe the export mechanism ain't it.

so, what is the perlish way to do this?

I would probably put it in a module, and use that module where I need to
know that value.
related question---if I want to break a program into a couple of
different files, what is the recommended way of doing this?

Normally breaking up a program afterwards in modules is a major task. A
lot of refactoring might be needed, and quite some back to the drawing
board.
is it
stuffing different routines into different modules? I am thinking of
something like the numerical recipees version, where I have hundreds of
subroutines. there, they put every sub into its own equal-named file.
of course, I may need 'em all in my program.

So you want a library based on NR? An important question is: how are the
users of this library going to look at things. Where do they expect a
certain functionality to reside?

I also guess that you either end up with a lot of class methods, or subs
programs can import (or a mix of this). Has been quite some time since I
browsed through my copy of NR though :)
 
I

ivowel

thanks, john.
I would probably put [a global variable] in a module, and use that module where I need to
know that value.

in all my files and subs. that means that every module and file may
need to import my "global variables" module in order to learn the
directory at hand. ok, so at least my guess was correct. it does not
seem unreasonable; I just wanted to not overlook the obvious.

Normally breaking up a program afterwards in modules is a major task. A
lot of refactoring might be needed, and quite some back to the drawing
board.

yes, this is why I was trying to figure out how I take a 10,000 line
perl source file with 50 subs, and split it into a few 1,000 line
files, each with 3-10 subs. (I only used numerical recipees as an
example, because I thought it was well known.)

see, I find program files more maintainable if each is less than a
thousand lines, more or less. In C, I would just create a variety of
..c files, and compile each into object files that are then linked.

in perl, I want to create a set of "equal" source files, each about 500
to 1,500 lines long, and each contains various subs. these source
files and their subs don't have clear module type functions. one may
call the other, etc. thus, a module seems like the wrong way to go.

should I have a main program that "#include"'s each of these 1,000 line
program chunks? how would I even do this? load a perl file into a
variable and then eval it,l or is there a perl built-in?

regards,

/iaw
 
J

John W. Krahn

what is the perl-ish way to define a global variable that is used by
many modules (e.g., the location of all databases, or of a particular
server)? Clearly, I want to define it only once, and have it be
accessible everywhere.

You could always use the %ENV hash. :)


BEGIN { $ENV{ database_location } = '/location/of/databases' }




John
 
J

John Bokma

thanks, john.
I would probably put [a global variable] in a module, and use that
module where I need to know that value.

in all my files and subs. that means that every module and file may
need to import my "global variables" module in order to learn the
directory at hand. ok, so at least my guess was correct. it does not
seem unreasonable; I just wanted to not overlook the obvious.

Why do all your modules need to know this variable? Can't you move the
code that needs this variable (or variables) to a module of its own and
use that module? For example for one project I put the database info in a
'database' module which had a constructor that just returned a database
connection (named connect :), and some other code that made my life a bit
easier.

[..]
yes, this is why I was trying to figure out how I take a 10,000 line
perl source file with 50 subs, and split it into a few 1,000 line
files, each with 3-10 subs. (I only used numerical recipees as an
example, because I thought it was well known.)

I know it, bought the C or Pascal version ages ago :).

[..]
should I have a main program that "#include"'s each of these 1,000
line program chunks? how would I even do this? load a perl file into
a variable and then eval it,l or is there a perl built-in?

perldoc -f require
 
M

Mumia W. (on aioe)

[...]
in perl, I want to create a set of "equal" source files, each about 500
to 1,500 lines long, and each contains various subs. these source
files and their subs don't have clear module type functions. one may
call the other, etc. thus, a module seems like the wrong way to go.

should I have a main program that "#include"'s each of these 1,000 line
program chunks? how would I even do this? load a perl file into a
variable and then eval it,l or is there a perl built-in?

regards,

/iaw

You could use "do 'filename';" or even better, "require 'filename';".
These would be good solutions if you haven't separated the the functions
into different packages, and it seems you haven't done that.

The main program might look like this for example:

#!/usr/bin/perl
require 'segment-one.pl';
require 'segment-two.pl';
require 'segment-three.pl';
.... use those functions ...

Lexical variables defined in those "segments" would not be visible in
the main program however, so you would have to make them package variables.

And if you're going to create a program with tons of package variables,
it's probably a good idea to place your entire program in its own
package, e.g.

#!/usr/bin/perl
package Application::Ivowel::HTTP;
require 'segment-one.pl';
....

And each one of the segments would also be in the
Application::Ivowel::HTTP package.
 
I

ivowel

thank you very much everyone for the suggestions. my next perl program
will be better.

regards,

/iaw
 
X

xhoster

what is the perl-ish way to define a global variable that is used by
many modules (e.g., the location of all databases, or of a particular
server)? Clearly, I want to define it only once, and have it be
accessible everywhere.

my first inclination was to put it into base.pm and use the Exporter to
just export it. its a bit of a pain, especially if the program itself
calls other modules, all of which have to import the base module
themselves, too. But it is doable.

I don't export any variables, and just create a module that everyone in my
group uses and then use the fully qualified variable name.

open my $fh, "$XhoGrp::datadir/foo/bar.txt" ....
related question---if I want to break a program into a couple of
different files, what is the recommended way of doing this?

How you do it depends on why you are doing it.

Xho
 
P

Peter J. Holzer

related question---if I want to break a program into a couple of
different files, what is the recommended way of doing this? is it
stuffing different routines into different modules? I am thinking of
something like the numerical recipees version, where I have hundreds of
subroutines. there, they put every sub into its own equal-named file.
of course, I may need 'em all in my program.

That made a lot of sense for a library of subroutines given the way the
Unix linker works with static libraries: The smallest unit the linker
can handle is the object file, so if you have lots of functions which
are mostly unrelated and you don't know which of them the user will need
you get minimal space usage if each function is in an object file of its
own.

Of course these days static libraries are out of fashion and with
dynamic libraries the constraints are different.


With Perl the constraints are different still. I wouldn't worry much
about speed and memory usage unless benchmarks show it's an issue. Try
to put functions which are in some sense related (they do similar
things, they call each other, etc) into the same file, so that you, the
maintainer, can easily find them, and so that changes in one file don't
cause changes in other files.

hp
 
P

Peter Scott

now, looking at Damien's perl6's suggested replacement for Exporter, I
did not find a way to export scalars. it just seems to export subs.
so maybe the export mechanism ain't it.

A quick glance at the source reveals that Perl6::Export should work with
`our $variable is export...'. Personally I prefer Exporter::Simple, it
doesn't use source filtering.
 
H

Henry Law

what is the perl-ish way to define a global variable that is used by
many modules (e.g., the location of all databases, or of a particular
server)? Clearly, I want to define it only once, and have it be
accessible everywhere.

In an application I wrote recently I created a module called "Global"
which reads all the universally-required information out of an XML
configuration file and exports a hash called %globals. Every main
program "uses" Global and every subroutine expects a reference to the
global hash as the last parameter. Works well for me.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,999
Messages
2,570,246
Members
46,839
Latest member
MartinaBur

Latest Threads

Top