How to include a large number of constants?

[noslenj123]

I am working on a program that has several hundred constants and I'm trying to figure out a good way to include those via a required file or a used module. I've run into problems and looking for advice.

If I require a file full of constants in g1.inc like

use constant FAILURE_CONF  => 1;
use constant FAILURE_EVENT => 2;
use constant OPEN_REQ      => 3;
use constant OPEN_CONF     => 4;

1;

And use it like

use strict;

require "g1.inc";

if ( 3 == OPEN_REQ ) {
    print "Code is OPEN_REQ\n";
} else {
    print "Code is NOT OPEN_REQ\n";
}

I receive: 'Bareword "OPEN_REQ" not allowed while "strict subs"'. I had thought for some reason requiring a file is like inserting that code at that spot in the script. Is it a compiletime vs runtime issue?

If I use a module, what is the briefest way to pass my large number of declared constants into the main namespace without retyping everyone of them into @EXPORT?

I await your witty wisdom. :-)

[dragonchild]

Yes, it is a compile-time vs. run-time issue. You could enclose your require statement in a BEGIN{} block and do just fine.

As for your second question, you could have all your constants have a common prefix, like C_. Then, you can do a little introspection as so:

package Constants;

use base 'Exporter';
our @EXPORT = grep {
    substr( $_, 0, 2 ) eq 'C_'
 && __PACKAGE__->can( $_ );
} keys %Constants::;


use constant C_FOO => 1;
use constant C_BAR => 2;
use constant C_BAZ => 3;

[5mi11er]

++ to the last three answers!    I am currently in need of just this type of thing.
I'm out of votes today, and needed a 'bookmark' here to remember to come back tomorrow...

-Scott

[doom]

This is actually very cool:

package Constants;

use base 'Exporter';
our @EXPORT = grep {
    substr( $_, 0, 2 ) eq 'C_'
 && __PACKAGE__->can( $_ );
} keys %Constants::;

The way I used to do it was to essentially use a source filter: I'd have a BEGIN block inside my Definitions.pm file read the file itself in and look for "use constant" lines:
Constant Amusement (auto export trick)

Anyone doing a lot of work with perl constants might want to skim through those talk notes, by the way. And in general, these days I'd recommend staying away from constants altogether -- their utility rarely makes up for their annoyances (e.g no sigil, so they don't interpolate very smoothly). Also a case can be made for keeping definitions of things in a YAML file instead of using perl code to store configuration (programmatic modification of YAML is a lot easier than parsing perl).

[Zaxo]

require is to happen at runtime, which leaves the compiler with a bareword and nothing to match in the symbol table. Arrange to use the file instead, since that happens at compile time.

[BrowserUk]

do file is probably the simplest way. Otherwise, you have to arrange for them to be exported from the modules namespace into the callers.

do 'g1.inc';

[noslenj123]

I tried using "do 'g1.inc';" but I get the same results as require with the bareword warning...

[BrowserUk]

For the constant subs to be recognised as such when the code that calls them is compiled, you'll need to put the do in a BEGIN{} block.

BEGIN{ do 'gi.inc'; }

[jhourcle]

I cheat, personally. I have a program which loads all of its contents from an XML file.

I think I've got this down the bare minimum required to be a useful example. (there's a few different type of config parameters, not all of which get exported, and logic for adding new values)

Read more... (1135 Bytes)

Update: You'd of course want to swap EXPORT_OK and EXPORT, so you don't have to pass in which constants you wanted to import (also cleaned up a typo, and split a paragrah)

[holli]

You may want to study the code of Astro::Constants.

[dragonchild]

Wow, that distribution is a poster-boy for how to (ab)use Module::Build. The author creates his modules on the fly during the build process, which is kinda nuts. More importantly, he pre-generates a list of constants ahead of time, then the modules end up explicitly listing every constant. The resulting files are going to look ... well ... ugly.

Now, the process the author uses is kinda nice. Maybe that should be replicated, but definitely not the resulting code.

[Grygonos]

Try this..

use constant {FAILURE_CONF  => 1,
              FAILURE_EVENT => 2,
              OPEN_REQ      => 3,
              OPEN_CONF     => 4};

Should simpllify the code a bit, visually speaking.

[perrin]

Make your g1.inc into an actual module with a package name and then just reference them with fully-qualified names, e.g. MyConstants::OPEN_REQ().

[noslenj123]

Thanks for all your suggestions. I have put several of them to use.

perrin's suggestion works fine, but adds verbosity.

Using 'do' didn't seem to help and gave me the same error.

zaxo confirmed the compiletime issue.

Thus, dragonchild's suggestion for using BEGIN worked fine. Also, I really like his wizardry for getting all the constants into @EXPORT without typing them all. I incorporated that technique. Thanks!

I also used Grygonos's suggestion simplifying the creation of all the constants.

I'm gonna need to spend some time studying jhourcle's XML technique.

friedo's technique looks similar to dragonchild's but I didn't have enum.pm installed so haven't checked it out yet.

I have learned many lessons o wise ones!

[friedo]

At a previous job I used enum and a bit of symbol-table trickery:

package Constants;
use base 'Exporter';

use enum qw(:C_ FOO, BAR, BAZ);

our @EXPORT = grep /^C_/, %{__PACKAGE__ . "::"};
1;

[sir.shz]

I'll just put them in a separate module:

package Constants;
use strict;
use Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(FOO $BAR @A %H)

use constant FOO => 1;
our $BAR = "bar";
our @A = (1,2,3,4);
our %H = (a=>1,b=>2);

1;

Then in your main script:

use strict;
use Constants;

print FOO,"\n";
print $BAR,"\n";
print join(",",@A),"\n";
print "$_=>$H{$_}," foreach keys %H;

[noslenj123]

Of course that is normally what I do. But I will have several hundred of your F00's and don't want to type them all into @EXPORT.

[phaylon]

How about organizing them with %EXPORT_TAGS? You cou then just say

use MyModule qw(:group1 :group2);

It should also be possible to pack smaller groups together in larger ones.

[salva]

do "g1.inc"

will do!