*prod = \%main::prod;
our %prod;
[download]

Thank you; it all sounds highly feasible. However, this is unfamiliar territory. Should I be putting this statement *prod = in the originating file (it isn't an OO package - at least I don't think it is) where %prod is populated or should I be putting it in the package that currently can't access it? Or both?

thanks a lot for your help.

In the package that currently can't access it.

Actually the really right way to do it is to move %prod into a configuration module that might look like this:

package My::Configuration;
use strict;
use Export qw(import);
our @EXPORT_OK = qw(%prod);
our %prod = (
  ...
);

1;
[download]

and then somewhere in main and in your other package insert the line:

use My::Configuration qw(%prod);
[download]

Doing that you won't even need the our declaration because importing it declares it.

our %prod; creates an alias named %prod to the variable %PKG::prod, where PKG is the package in which the our is located.

The alias exists until the end of the lexical scope (curlies or file).

# ModuleA.pm

package ModuleA;
our %prod;
# %prod is aliased %ModuleA::prod

package ModuleA::Helper;
# %prod is still aliased %ModuleA::prod

1;
[download]

# ModuleB.pm

package ModuleB;
our %prod;
# %prod is aliased %ModuleB::prod

1;
[download]

I'd suggest using Exporter:

# Module1.pm
package Module1;
our %variable;
use base 'Exporter';
our @EXPORT_OK = qw(%variable);

%variable = ( foo => "foo" );

# Module2.pm
package Module2;
use Module1 qw(%variable);

print $variable{foo};
[download]

However, if you plan to use this variable to exchange data between the modules, I'd suggest using subroutine arguments instead.

There seems to be very little on the function "our" in manuals and tutorials.

This observation is correct, and that's because there are few if any projects that are not improved by a global s/our/my/.

Of course that will break your existing system of letting everybody share the same global variable. This is generally considered a good thing.

In the file where you declare and populate my %prod, follow it up with an offer to share:

sub get_prod_ref {
    return \%prod;
}
[download]

and now let client files say

use My::Configuration; 
my $prod_ref = My::Configuration::get_prod_ref();
# or if you prefer
my %prod = %{ My::Configuration::get_prod_ref() };
[download]

there are few if any projects that are not improved by a global s/our/my/.

You can easily support use My::Configuration qw( %prod );. Although the basic Exporter.pm doesn't support exporting of lexicals, it is dead easy to support that yourself and I strongly suspect that at least one of the "better exporter than Exporter" modules on CPAN is already written to allow you to export lexicals as well.

But just to prove how easy it is, if you only have one variable to potentially export, I roll my own exporter as you watch:

package My::Config;
use strict;

my %prod = ( foo => 'bar' );
my %export= ( '%prod' => \%prod );
sub import {
    my ( $me, @syms )= @_;
    my $caller= caller();
    for my $sym ( @syms ) {
        my $ref = $export{$sym};
        if ( ! $ref ) {
            require Carp;
            Carp::croak( __PACKAGE__, " does not export $sym\n" );
        }
        $sym =~ s/^[\$\@\%]//;
        no strict 'refs';
        *{ $caller.'::'.$sym }= $ref;
    }
}
[download]

Heh, that one isn't even limited to just exporting one variable (it doesn't support exporting groups of symbols yadda, of course).

- tye        

It is hard to justify such code in any serious context.

This is written to be an object method but it effects the object's package namespace not the object.

This is code that should not be applied to mature code since the My::Config module needs be invaded and all the client code needs to be altered to use it. If there is already a My::Config::import function, it would be better to change the lexicals to package variables inside My::Config.

If writing new code, such misuse of lexicals is perverse. ... That is the thing I like about it. Ahh.

Be well,
rir