perl-ish global variable?

Discussion in 'Perl Misc' started by ivowel@gmail.com, Dec 17, 2006.

  1. Guest

    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
     
    , Dec 17, 2006
    #1
    1. Advertising

  2. John Bokma Guest

    wrote:

    > 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 :)

    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
     
    John Bokma, Dec 17, 2006
    #2
    1. Advertising

  3. Guest

    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.


    > > 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.
    >


    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
     
    , Dec 17, 2006
    #3
  4. wrote:
    > 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
    --
    Perl isn't a toolbox, but a small machine shop where you can special-order
    certain sorts of tools at low cost and in short order. -- Larry Wall
     
    John W. Krahn, Dec 17, 2006
    #4
  5. John Bokma Guest

    wrote:


    > 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


    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
     
    John Bokma, Dec 17, 2006
    #5
  6. On 12/16/2006 09:47 PM, wrote:
    > [...]
    > 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.


    --

    http://home.earthlink.net/~mumia.w.18.spam/
     
    Mumia W. (on aioe), Dec 17, 2006
    #6
  7. Guest

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

    regards,

    /iaw
     
    , Dec 17, 2006
    #7
  8. Guest

    wrote:
    > 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

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Dec 17, 2006
    #8
  9. On 2006-12-17 01:28, <> wrote:
    > 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

    --
    _ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
    |_|_) | Sysadmin WSR | > ist?
    | | | | Was sonst wäre der Sinn des Erfindens?
    __/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
     
    Peter J. Holzer, Dec 17, 2006
    #9
  10. Peter Scott Guest

    On Sat, 16 Dec 2006 17:28:40 -0800, ivowel wrote:
    > 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.

    --
    Peter Scott
    http://www.perlmedic.com/
    http://www.perldebugged.com/
     
    Peter Scott, Dec 18, 2006
    #10
  11. Henry Law Guest

    wrote:
    > 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.

    --

    Henry Law Manchester, England
     
    Henry Law, Dec 21, 2006
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Boland

    VB(ish) replacement

    Dave Boland, Jul 20, 2004, in forum: Perl
    Replies:
    4
    Views:
    603
    Joshua Kugler
    Sep 11, 2004
  2. Gummy
    Replies:
    4
    Views:
    395
    Gummy
    Mar 31, 2006
  3. joseph white

    1979-ish web site?

    joseph white, Dec 3, 2004, in forum: HTML
    Replies:
    89
    Views:
    2,137
  4. - Bob -
    Replies:
    1
    Views:
    2,235
    - Bob -
    Oct 7, 2007
  5. - Bob -
    Replies:
    2
    Views:
    138
    - Bob -
    Oct 9, 2007
Loading...

Share This Page