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
Pretty much, yes - the primary purpose of exporting symbols (sub or variable names) is just so that you don't need to provide the fully-qualified name every time you reference the symbol. 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]

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]