Thanks for posting this!

One thing that might be a surprising side-effect of your approach is, that it will re-export all functions in the module, even if they were imported themselves already:

package My::Package;

use List::Util 'max';
use Exporter qw(import);
@EXPORT_OK = (keys %My::Package::);
[download]

... will also happily export the max subroutine.

It won't work the first time you do it because My::Package hasn't been loaded at the time that you try to get the list of keys in order to pass in to the 'use' line. The second time you use it, it might work, but it will still be a really bad idea.

use My::Package '/./';
[download]

See 'Advanced features' in Exporter.

Ah, the trick is that the 'use' line becomes:

BEGIN {
    require My::Package;
    My::Package->import( keys %My::Package:: );
}
[download]

so the 'keys' expression is evaluated after the (generated) 'require My::Package;' is run.

(And I had a typo in my test case.)

- tye        

Surprisingly, it works at first launch (I used a simplified version to avoid having to create a file to be read):

$ perl -e '
 use strict;
 use warnings;
 use My::Package (keys %My::Package::); # 

 test("hello world\n");
 test_2("hello this is dog");
'
hello world
hello this is dog
[download]

But I am of course not saying it is a good idea to do that.

EDIT: Also am I right in thinking that the reason this works is because I am calling that specific module with keys %My::Package::. If i am wrong please help me understand... more better :)

# ...
use Exporter qw(import);
@EXPORT = (keys %My::Package::);  # @EXPORT instead of @EXPORT_OK
# ...
[download]

$ perl -e '
 use strict;
 use warnings;
 use My::Package;

 test("hello world\n");
 test_2("hello this is dog");
'
hello world
hello this is dog
[download]

#Package.pm

package My::Package;

use strict; #can use strict and warnings as usual now as well without 
+any warnings
use warnings;
use Exporter qw(import);

our @EXPORT = qw(print_lines test test_2); #just add in function names
+ as you make them
our %EXPORT_TAGS = (all => \@EXPORT);


sub print_lines{

    my ($input) = shift;

    while(<$input>){
        print;
    }
    close($input);
}


sub test{
    
    my ($input) = shift;
    print $input;
}

sub test_2{
    
    my ($input) = shift;
    print $input;
}
[download]

And here is the script calling it

#script.pl

use strict;
use warnings;

use My::Package qw(:all);


open (my $file, '<', shift);

print_lines($file);
test("hello world\n");
test_2("hello this is dog"); # i love this meme lol
[download]

That ":all" is what i was originally shooting for. Though I also figured out you could just require My::Package; and then just call it in the script with use My::Package; and do not have to specify any functions. Anyways, thanks for the help fellers :)

UPDATE: Also I wanted to ask, if I use strict and warnings in the main script, is that in the modules scope as well, or do I need to use strict and warnings in the module as well? Also IF strict and warnings are in the same scope, is it just for the functions/subs or the whole module?

UPDATE: Also I wanted to ask, if I use strict and warnings in the main script, is that in the modules scope as well, or do I need to use strict and warnings in the module as well?

'use strict' is a pragma that has lexical scope. Loading a module via use loads the module via require which notes "The file is included via the do-FILE mechanism, which is essentially just a variety of eval with the caveat that lexical variables in the invoking script will be invisible to the included code". So a lexical pragma will also not stay in effect.

So you need to 'use strict;' in each module.

- tye        

I suggest doing it this way:

our @EXPORT_OK = qw(print_lines test test_2);
our %EXPORT_TAGS = (all => \@EXPORT_OK);
[download]

Because when you set @EXPORT, the items in @EXPORT are automatically exported.

I suppose that it depends upon what you mean by the word, “safe.”   It might work ... yes, it might ... but any change to the module would also affect what it meant, because it does not say what it means.   Instead, it is “clever.”   From a project management point of view, and/or from the point of view of a fellow team-member who might get really tired of being “bit,” no, it is not safe.

The intent of this construct was clear:   to allow you to list exactly which of the possibly very-many subroutines in the package, you actually intend to use.   It is specifically envisioned to be both descriptive and limiting, and should be used in that fashion.