EvdB has asked for the wisdom of the Perl Monks concerning the following question:

I am rolling my own config module and considering two approaches. The idea behind the module is simply to provide one central place in which to stick all the fixed values that a typical website relies on (database name and password, file paths etc).

Method 1: the variable approach:

####### In Config module ########## package My::Config; $My::Config::DB_NAME = 'my_database'; $My::Config::DB_PASS = 'secret'; 1; ####### In another module ######### use My::Config; my $db_name = $My::Config::DB_NAME;

Method 2: The subs approach:

####### In Config module ########## package My::Config; sub DB_NAME { 'my_database' } sub DB_PASS { 'secret' } 1; ####### In another module ######### use My::Config; my $db_name = My::Config::DB_NAME;

Both work very nicely. The variable approach is almost as fast as doing my $db_name = 'my_database'; and three times faster than the subs approach.

I want to go with the sub approach because I can then be sure that the values will not change during the lifetime of the script (under mod_perl this could be a while).

QUESTIONS:

  1. Would it be possible to change the values of the returns from the subs if the subs approach is used.
  2. Are there any other factors that should be considered when making the choice.

--tidiness is the memory loss of environmental mnemonics

Replies are listed 'Best First'.
Re: Variables versus Subroutines for a Configuration Module.
by hardburn (Abbot) on Oct 10, 2003 at 16:25 UTC

    Would it be possible to change the values of the returns from the subs if the subs approach is used.

    Yes, by doing some tricks with the symbol table:

    use My::Config; no strict 'refs'; *'My::Config::DB_NAME' = sub { 'new_db' };

    Are there any other factors that should be considered when making the choice.

    Under certain conditions, subs declared with a prototype of () are considered for inlining (that's how use constant is implemented), which would make the sub method as fast as a hard-coded value. This is true as long as you don't call the sub as a class method. Example (which is tested on perl 5.8.0):

    $ perl -MO=Deparse -e ' > package Foo; > sub bar () { "baz" } > package main; > print Foo::bar(), "\n"; > print Foo->bar(), "\n"; > ' -e syntax OK print 'baz', "\n"; print 'Foo'->bar, "\n";

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

      Using the () in the sub that is a great tip - thank you. I presume that as the values are being effectively hardcoded in dureng compile that this makes it impossible to change it during runtime.

      --tidiness is the memory loss of environmental mnemonics

        Indeed, this is the case.

        Makeshifts last the longest.