in reply to Re: Re: using strict and a config file
in thread using strict and a config file

Remove the my declaration from your config file.

Declare your arrays with our in your program:

our @fields;
out @field_names;

[download]
Then require your config file:
require 'config_mailto.txt';

[download]
That should work.

Have a look at perldoc -f our and perldoc -f my for more info.

Replies are listed 'Best First'.
Re (tilly) 4: using strict and a config file
by tilly (Archbishop) on Nov 12, 2001 at 14:13 UTC
    There are a lot of people still using version 5.005_03, in which case the our solution is simply not an option. But even if you do have 5.6.x installed, I still am not convinced that it is a good idea. See Why is 'our' good? for some of my doubts.
[reply]
      I agree. In fact I think a better solution would be not to have Perl code in the config file but name/value pairs and read them into a hash.
      Perhaps even better use a CPAN module for the config file handling.
[reply]
        I disagree.

        There are plenty of legitimate reasons to want to have more complex data structures in a configuration than just a simple hash.

        Also while there are plenty of configuration modules on CPAN, I haven't seen any that I like very much. Here are the main capabilities that I want out of a configuration solution:

        1. Be able to have any kind of data structure into the configuration.
        2. Be able to have a search path with selective overriding of configuration information. For instance the development and production configurations should be as similar as possible, with only a few key values being overridden.
        3. Be able to selectively tie together the configurations of separate modules which should share some common information based on your environment.
        4. Have checks so that if someone is trying to access a variable from the configuration that isn't there, you can catch it and fix.
        On these criteria, most of the CPAN configuration modules score 0/4. Just using raw Perl as a configuration file scores 2/4. A simple bit of code that searches a configuration path and does every file it finds there with a specific name scores 3/4. And if you know what you are doing, it is possible to create a simple configuration module that adds the export checks.

        Now those wants are not everyone's. Everyone wants to get different things from a configuration module (which is one reason why there are so many configuration modules out there). But I claim that my list is not an unreasonable set of wants for a Perl programmer to have, and if you have them then pure Perl is a perfectly reasonable kind of configuration file to use.

[reply]

In Section Seekers of Perl Wisdom