I have a desire to do something like this.

In file MyPackage.pm:

package MyPackage;

our @Settings;

sub whatever
{
    # Use any externally supplied settings.
    print join("\n", @Settings), "\n";
}
[download]

In file MyConfig.pm:

package MyConfig;

# Set up code goes here ...

# Now switch to the other package and set values
package MyPackage;

our @Settings = (qw/a ab cdef ghi/);
[download]

It seems to work fine, but it seems a little evil (maybe that's making it more attractive :-). The reason for wanting to do this beyond the contrived example is this: I have some modules that do preliminary run-time set up based on environment, etc. That would be the role of the MyConfig.pm file in the example. These modules need to set up without invoking the actual packages that depend on what they set up -- it's a classic bootstrap/chicken-egg sort of problem. In other words, MyConfig may set values that change the way MyPackage gets invoked (or even where it gets invoked from). If I provide a nice interface in MyPackage, then MyConfig has to use MyPackage to use that interface, defeating the purpose of having preliminary set-up. On the other side, having MyPackage have to know to call out to a preliminary set-up package to pull set-up values in also seems like bad interface design -- I'd prefer to have the package do what it does and not have to worry about add-ons that change its behavior. In this specific sort of case, I'm extending the package interface to a pretty general "if you put something in here, no matter how you do it, I will use it" model.

What are opinions on doing this sort of thing, or ideas for not doing it? I'm also not sure if having an our declaration in two places is strictly kosher or if I'm just lucking out that it works. Maybe leaving our off is better practice in a case like this?