in reply to (tye)Re: How to set a set of our and @EXPORT variables concisely?
in thread How to set a set of our and @EXPORT variables concisely?

There we go! Thanks tye. I knew it could be done and thank you for showing how it can be done.

The only problem is: supposedly use vars is deprecated so this example must use our to remain viable in years to come. So, to use our, I guess we have to use eval 

use base qw( Exporter );
our @EXPORT;
BEGIN {
    @EXPORT= qw(
             $MC_CONFIG_DBI_DRIVER
             $MC_CONFIG_DB_NAME
             $MC_CONFIG_DB_USER
             $MC_CONFIG_DB_PWD
             $MC_CONFIG_FILE
             $MC_CONFIG_FEED_LOGS
             $MC_CONFIG_ARCHIVE_LOGS
    );
    eval "our $_;" for @EXPORT;
}

[download]

Replies are listed 'Best First'.
(tye)Re2: How to set a set of our and @EXPORT variables concisely?
by tye (Sage) on Nov 21, 2000 at 20:34 UTC

    But as you found out, the our declares a global variable but the lexical alias to it goes away when you leave the enclosing scope (either the eval or the BEGIN, I'm not absolutely sure which and it would be hard to test but it doesn't really matter here).

    So you still have to fully qualify the variable name in the rest of your script. As I already said, there is no good fix for this other than use vars.

    I see no mention of use vars being depricated. The closest thing I found was "NOTE: The functionality provided by this pragma has been superseded by `our' declarations". Since using our makes your script not work on even very slightly old versions of Perl, there will still be many scripts using use vars for quite a long time. So deleting vars.pm would be quite stupid of the perl porters, especially since it would be impossible to write version-portable code via something like: 

    BEGIN {
    if(  5.6 < $^V  ) {
        eval 'our $x; 1' or die $@;
    } else {
        require vars;
        vars->import( '$x' );
    }
}

    [download]
    for the exact same reasons that our doesn't work for your code.

    So don't worry about vars.pm going away until you actually read that is has been deprecated (not "superseded").

    Note that our makes for slightly more efficient code, and this is probably why the use vars documentation points you in that direction a little strongly. This efficiency is pretty trivial so I wouldn't sacrifice maintainability (by having two lists of variables to keep in sync) for it.

            - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]
A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom