Re^4: help with versioning modules

I was studying your examples again and came up with another question. Suppose I take your My/Bar.pm file and copy it as-is to a new file My/Xyzzy.pm. Now suppose I create a new file xyzzy_version_test.pl to reference and use this new module as follows:

#!/tool/bin/perl -w
use strict;
use lib '/home/user/perl_modules/lib/perl5/My';
use Xyzzy;

say_it();
[download]

Now the package name matches the file name. Running this code gives the following error:

Undefined subroutine &main::say_it called at ./xyzzy_version_test.pl l
+ine 6.
[download]

It seems that the package name Xyzzy is still explicitly required in this case to call the say_it function even though the package name now matches the filename. After doing some searching, I found that adding the following to My/Xyzzy.pm allows the above call to say_it() (without the Xyzzy->) to work:

use Exporter qw(import);

our @EXPORT = qw(say_it);

our @EXPORT_OK = qw();
[download]

My question is: are the above 3 lines of code that I added to My/Xyzzy.pm (and using qw() to reference specific subroutines in a package, e.g. use Xyzzy qw(say_it);, had I included say_it in the EXPORT_OK list rather than the EXPORT list) only used to prevent the user from having to prefix every call to a exported subroutine with Package-> every time, or do they serve other purposes?

Comment on Re^4: help with versioning modules Select or Download Code

Replies are listed 'Best First'.

Re^5: help with versioning modules
by dsheroh (Monsignor) on Jan 05, 2021 at 08:40 UTC

The error message you got hints at the internals behind this - it complains that it couldn't find &main::say_it, but, because the sub is in package Xyzzy, its actual fully-qualified name is &Xyzzy::say_it. Exporting the sub creates a new reference to say_it in the package that you use the module from (which, in this case, defaults to package main, since you aren't explicitly inside a different package).

When you're writing object-oriented code (which is where the -> syntax is normally used), you generally don't need (or want) to export the subs implementing your methods, because they should be called from an object reference ($my_object->do_stuff()), so exporting is usually only used for non-OO procedural interfaces where the subs would be called as stand-alone chunks of code.

Also, as a side note regarding EXPORT vs. EXPORT_OK, it's generally considered better to use EXPORT_OK, so that symbols are only exported by explicit request. This helps to avoid conflicts (what if you had already defined your own sub say_it, then you use Xyzzy and it implicitly exports its own say_it?) and makes it easier to locate where things came from while debugging (if you use 15 modules that all implicitly export subs, you can't find where say_it was defined without checking every one of those modules, but use Xyzzy qw(say_it) makes it obvious where it came from).

[reply]
[d/l]
[select]


Don't ask to ask, just ask
	PerlMonks