I have a desire to do something like this.
In file MyPackage.pm:
# Use any externally supplied settings.
print join("\n", @Settings), "\n";
In file MyConfig.pm:
# Set up code goes here ...
# Now switch to the other package and set values
our @Settings = (qw/a ab cdef ghi/);
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?