Exporting all variables and subroutines using Exporter

[t-rex]

Hi monks, I want to export all variables and subroutines of one module to another, is there a way to do it , coz what i know so far is using

 
use Exporter 'import'; 
@EXPORT_OK = qw(sub1 sub2 var1 var2);

my issue with the above method is one of my modules contain all variables and i have many dependencies on other modules, i know this might not sound a great idea but since i am in middle of project i can't lead to drastic changes in the design coz of time issues. I have come across Exporter::Auto but i don't know how reliable it is and please let me know how can i install the module, as i didn't find it on cpan, thanks

[choroba]

Exporter::Auto is on CPAN, how did you search? It only exports subroutines, though, not variables.

Your explanation of the situation is unclear. As you suspect, exporting everything is a bad idea, especially when you don't know what exactly you want to export. Also note that

@EXPORT = qw( var1 );

doesn't export $var1 , @var1 , or %var1 , but &var1 . The sigil isn't optional here.

[t-rex]

i used Exporter :: Auto and now i can export functions but variables i am unable to use , is there any way i can use the variables:

for ex: 

main .pl
package1.pm
package2.pm
package3.pm

now my use case is such that package1.pm contains all the variables wh
+ich will be used in main.pl and package2.pm and package3.pm

the actual code is too large so i am just posting what exactly i want. i hope i am clear with it .

[haukex]

Hi t-rex,

If both files happen to use the same package name, there is no exporting needed. Saying "all variables and subroutines" is unclear: Do you want to export only package globals or lexical variables (my) as well? You could also clarify these things by providing some example code. I'm also guessing you only want to export things you defined yourself, but the package symbol table will actually end up having more stuff in it than you'd probably like to export (for example, defining an array our @arr also causes a scalar $arr to show up in the symbol table reported by Devel::Symdump!), so I think automating the export by looking into the symbol table is probably not a good option. How many functions and variables are you talking about? If it's a reasonable number, it might just be easier to type them into @EXPORT_OK than to attempt an automatic export. Or, adjust the package names so they match, and don't worry about exporting at all.

Hope this helps,
-- Hauke D

[Eily]

What Exporter::Auto (no problem finding it on CPAN ...) does is check into the symbols table (a hash with the same name as the module that contains all the symbols accessible from this module) for symbols with a CODE section (ie: that are the name of a sub) and that were not imported from another module (or used to alias another name). You could work from that (by reading the source of Exporter::Auto, which is pretty short), or, if I understood correctly, and you want all your variables from OldPackage into NewPackage, just replace package OldPackage; with package NewPackage; at the top of your module, and have use OldPackage; as the first line of your second module.

[t-rex]

i want to reuse the variables from one package to many different packages.

[hippo]

Sounds like you want vars::global.

[BrowserUk]

Instead of trying export everything into your current package, it would be simpler to remove the package statement from the top of the file and use do 'module.pm'; to effectively include it into the current namespace.

do 'filename'; is almost forgotten, little used syntax, but it achieves your goal exactly without needing to jump through hoops and replicate a mass of stuff in two different namespaces.

[t-rex]

i tried it, that doesn't work

[BrowserUk]

that doesn't work

Oh, but it does "work"; and has done since perl 4 days. Here's proof:

fred.pm:

#package fred;

sub X123{ return 'x123'; }

sub Y456 { return 'Y456'; }

$localScalar = 'from fred';
@localArray = qw[ also from fred ];
%localHash = qw[ and this comes from fred as well ! ];

print 'fred.pm loaded';

And junk33.pl that does it:

#! perl -slw

do './fred.pm' or die "$@ / $!";

print $localScalar;
print @localArray;
print %localHash;

print X123();
print Y456();

And the output from a run:

C:\test>junk33
fred.pm loaded
from fred
alsofromfred
well!comesfromandthisfredas
x123
Y456

See subs and variables 'exported' into the calling code.

Of course, if you enable warnings, you do get a few:

C:\test>junk33
Name "main::localArray" used only once: possible typo at C:\test\junk3
+3.pl line 6.
Name "main::localHash" used only once: possible typo at C:\test\junk33
+.pl line 7.
Name "main::localScalar" used only once: possible typo at C:\test\junk
+33.pl line 5.
fred.pm loaded
from fred
alsofromfred
well!comesfromandthisfredas
x123
Y456

And if you enable strict, things start to fall apart:

C:\test>junk33
Global symbol "$localScalar" requires explicit package name at C:\test
+\junk33.pl line 6.
Global symbol "@localArray" requires explicit package name at C:\test\
+junk33.pl line 7.
Global symbol "%localHash" requires explicit package name at C:\test\j
+unk33.pl line 8.
Execution of C:\test\junk33.pl aborted due to compilation errors.

And that is my point. do 'file' is "is almost forgotten, little used syntax," for a reason; Perl 5 vastly improved upon the mechanisms available in Perl4, by introducing packages & namespaces & lexical variables, and the tools (require & use) to make use of them.

And in order to achieve what you are asking for in the OP, is to return to Perl4 -- which Perl will allow you to do -- but to achieve it you need to throw away namespaces and packages and lexical variables and strict & warnings. If you're prepared to do that, perl makes it simple. If you are not; then you might reconsider the reasons why you want to do it.

I could have told you: thou shalt not; but it's better that you understand the reasons why it probably better that you don't; that you understand the trade offs; and what you have to give up in order to avoid re-structuring the code that you are so adamant that you cannot do.

In other words; what you are asking for is doable; but given the trade-offs, you'll probably decide that you don't actually want to do it any more. But it is your decision to make.

[$h4X4_|=73}{]

For variables you would want to use Exporter for the subroutines you would want to use AutoLoader


BEGIN {
use strict;
use warnings;
  use vars qw
  (
@ISA @EXPORT $var1 %var2 @var3
  );

  require Exporter;
  require AutoLoader;

@ISA    = qw(Exporter AutoLoader);
@EXPORT = qw(sub1 sub2 $var1 %var2 @var3);
}
# ...

You may or may not need to use "BEGIN". What I do is drop AutoLoader and just use Exporter. Because an object/OO can have all its methods in the object variable and you can pass that around with exporter instead of autoloader.

Update: Another way is to just call the subroutine with the class it was in. Because if you have required it in one part of the currently running script it should still be loaded package1::sub1(); and for variables you can use this in the package our $var1; or use vars qw( $var1 ); is the same. Then call variables like $package1::var1