How to import all "our" variables from an unnamed Perl module without listing them?

Question

I need to import all our variables from an unnamed Perl module (Module.pm) and use them inside a Perl script (Script.pl).

The following code works well without "strict use , but failed with it. How can I change this code to work with " use strict " without manually listing all imported variables (as described in the answer to another question )?

Many thanks for your help!

Script.pl:

use strict; require Module; print $Var1; 

Module.pm:

 our $Var1 = "1\n"; ... our $VarN = "N\n"; return 1; 

Run the script:

 $> perl Script.pl 

Errors:

 Global symbol "$Var1" requires explicit package name at Script.pl line 3. Execution of Script.pl aborted due to compilation errors. 

NOTE (1) : the module has no name, so using the module Module:: prefix is ​​not an option.

NOTE (2) : Module.pm also contains a set of functions configured by global variables.

NOTE (3) : variables are different and should NOT be stored in the same array.

NOTE (4) : the design is NOT good, but the question is not the design. This is about forcing the specified code to work with minimal changes with O(1) complexity, that is, several lines of code that are independent of N

Candidate for Solution (ACCEPTED) : Add $:: in front of all imported variables. It conforms to strict , and also allows you to distinguish between my and imported variables in code.

Answer 1

Change the script to:

 use strict; require Module; print $Module::Var1; 

The problem is that $Var1 is not in the main namespace, but in the Module namespace.

Edit: As indicated in the comments below, you did not name your module (i.e. it does not say package Module; at the top). Because of this, there is no Module namespace. Change script to:

 use strict; require Module; print $main::Var1; 

... allows the script to correctly print 1\n .

Answer 2

If you need to import all of our variables in each module, something seriously doesn't fit your design. I suggest you redesign your program to separate the elements so that there is a minimum of crosstalk between them. This is called decoupling .

Answer 3

It looks like you have data in a file and you are trying to load this data into your program.

As of now, our declarations in the module only declare variables for the scope of this file. Once the file ends, in order to access the variables, you need to use their full name. If your module has the string package xyz; , then the full name is $xzy::Var1 . If there is no package declaration, then the default main package is used, giving your variables the name $main::Var1

However, anytime you do a lot of variables with numeric name variables, you should probably use an array.

Change your module to something like:

 @My::Module::Data = ("1\n", "2\n" ... ) 

and then access the elements by index:

 $My::Module::Data[1] 

Answer 4

Do you want to export all the variables from the module, and want to do it so that you don’t even know what you are exporting? Forget about use strict and use warnings , because if you put them in your program, they just start screaming and curl up in the corner, crying hysterically.

I never, and I mean almost never, never export variables. I always create a method to retrieve the required value. This gives me vital control over what I expose to the outside world, and it maintains a clean username space.

Look for possible problems with your idea.

• You have no idea what is exported in your module. How will a program that uses this module know what to use? Somewhere you have to document that the variable $foo and @bar are available for use. If you need to do this, why not just play safely?
• You have a problem with someone who is changing a module, and suddenly a new variable is exported to the program using this module. Imagine this variable is already in use. The program suddenly has an error, and you can never understand it.
• You export the variable to your module, and the developer decides to change this variable or even remove it from the program. Again, because you have no idea what is being imported or exported, there is no way to find out why the error suddenly appeared in the program.

As I mentioned, you have to find out somewhere that is used in your module that the program can use, so you should document it anyway. If you intend to insist on importing variables, at least use the EXPORT_OK array and Exporter module. This will help limit damage. That way, your program can declare which variables depend on it, and your module can declare which variables it knows which programs can use. If I modify a module, I will be more careful with any variable that I see during the export process. And, if you must indicate in your program which variables you are importing, you know that you will be careful about these specific variables.

Otherwise, why bother with modules? Why not just go back to Perl 3.0 and use require instead of use and forget about using the package statement.