PERL modules named differently than the package won't export

Hi, all:

I have different versions of a module, say Utils1.pm and Utils2.pm with different filenames but they all have the same package name. I want a .pl file to be able to use whatever version it wants.

Here's the module:

package Utils;

use strict;
use warnings;
require Exporter;

our @ISA = qw(Exporter);
our @EXPORT = qw(Log); # symbols to export on request

sub Log {
  my $message = shift;
  print STDERR "$message\n";
}

# Note that Log() is also called from the Utils namespace:
sub Start_app {
  Log("App started.");
  # Handle other stuff

}

1;

[download]

And it exports a few functions that are used at many points int the code. Because the function is used so many places, I want to improve readability by not explicitly referencing the package in app.pl.

Then we have the app.pl:

#This file: app.pl
use strict;
use warnings;

use Utils1;

Log("App started");
[download]

But I get this when running it:

$ perl app.pl
Undefined subroutine &main::Log called at app.pl line 8.
$
[download]

How do I get Log() imported into main? TIA

Comment on PERL modules named differently than the package won't export Select or Download Code
Re: PERL modules named differently than the package won't export by Eliya (Priest) on May 14, 2012 at 16:48 UTC
The problem is that if you use a different name in the use statement than what you have named the package, Perl will try to call the import method on the wrong package. In your case, it tries to call `Utils1->import`, and, as there is no such package/method, nothing is being called and consequently nothing imported. So don't do this. Or if you really want to, make the appropriate import call yourself. I.e. instead of `use Utils1`, write: `BEGIN { require Utils1; Utils->import; }` [download]	[reply] [d/l] [select]
Re^2: PERL modules named differently than the package won't export by kovacsbv (Initiate) on May 15, 2012 at 16:44 UTC
Thanks, Eliya. That solved the problem. Now I can modify the .pm and use it in a more risk-tolerant .pl and when we're all comfortable that it won't blow up, we can start moving it into other .pl files that are risk-averse.	[reply]
Re: PERL modules named differently than the package won't export by dsheroh (Parson) on May 15, 2012 at 10:00 UTC
I'll second the "don't do this". Given that you don't need to include the package name when referencing an exported symbol, what do you hope to achieve by having two separate source files, with two separate names, which contain alternate implementations of the same package?	[reply]
Re^2: PERL modules named differently than the package won't export by kovacsbv (Initiate) on May 15, 2012 at 13:59 UTC
Version control of PMs where different callers (that is, different .pl files) can each choose which version of the PM they want by simply changing the use statement, not multiferous lines that call into the module. That is my goal.	[reply]
Re^2: PERL modules named differently than the package won't export by kovacsbv (Initiate) on May 15, 2012 at 16:40 UTC
Oh, yeah one more thing. Most functions are not exported; they have to be explicitly referenced (to avoid too much namespace pollution). But there are two or three that are used so often it just makes more clutter to require explicit reference.	[reply]
Re^3: PERL modules named differently than the package won't export by dsheroh (Parson) on May 16, 2012 at 07:32 UTC
I see. I guess that makes (some) sense. How about this approach, then: As Eliya mentioned, `use Utils1;` is equivalent to `BEGIN { require Utils1; Utils1->import; }` [download] You should, therefore, be able to make the import from the Utils package transparent by editing Utils1.pm to do something along the lines of `package Utils1; sub import { Utils->export_to_level(1, @_); } package Utils; ...` [download] This will (assuming I remembered the incantation correctly) make `Utils1->import` equivalent to `Utils->import`. Although, really, the better approach would likely be to put the two versions of `Utils.pm` into different library directories (e.g., `/usr/local/devel/Utils.pm` and `/usr/local/stable/Utils.pm`), then manipulating `@INC` (by setting `PERL5LIB` in the shell or with `use lib` in the code) so that each program will load the appropriate version.	[reply] [d/l] [select]


Keep It Simple, Stupid
	PerlMonks

PERL modules named differently than the package won't export

The best material for plates (tableware) is: