Is it incorrect for a module to "use" subroutines from itself?

H

Henry Law

I have some code of which this is the relevant part:

package NFB::Utilities::Common;
# ...
our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
db_connect get_file_gm_info
# etc ... ('all' is defined but I've snipped it)
) );

# ... other subs

sub db_connect {
# ...etc
}

sub get_file_gm_info {
# 'db_connect' is actually in this module. The call
# is left over from when the sub was developed in-line.
use NFB::Utilities::Common qw(db_connect);
}

I'm trying the code newly-installed on a Fedora Core 6 system running
Perl 5.8.8 and it fails to compile, complaining that (in the above
example) "db_connect" is not exported by the NFB::Utilities::Common
module". It's clear that it is exported. Commenting out the offending
lines, where the module uses subroutines from itself, fixes the problem.

That's OK: I can easily find and remove the offending lines. But the
code runs clean on an FC5 machine also running perl 5.8.8, and on my
Windows machine running ActiveState 5.8.8, so I'm worried that I'm
chasing a secondary error, actually caused by something else.

Does anyone have any insight on this? Seen it yourselves, perhaps?
 
G

Gunnar Hjalmarsson

Henry said:
I have some code of which this is the relevant part:

package NFB::Utilities::Common;
# ...
our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
db_connect get_file_gm_info
# etc ... ('all' is defined but I've snipped it)
) );

# ... other subs

sub db_connect {
# ...etc
}

sub get_file_gm_info {
# 'db_connect' is actually in this module. The call
# is left over from when the sub was developed in-line.
use NFB::Utilities::Common qw(db_connect);
}

To me, that use-statement makes no sense at all. You don't need to load
the module, since it's obviously already loaded, and the "db_connect"
symbol is already in the NFB::Utilities::Common package, so why on earth
would you want to import it to that same package?

HTH
 
X

xhoster

Henry Law said:
I have some code of which this is the relevant part:

package NFB::Utilities::Common;
# ...
our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'}}, qw(
db_connect get_file_gm_info
# etc ... ('all' is defined but I've snipped it)
) );

Presumably there is also a relevant part where you
put Exporter in ISA, or use base.
# ... other subs

sub db_connect {
# ...etc
}

sub get_file_gm_info {
# 'db_connect' is actually in this module. The call
# is left over from when the sub was developed in-line.
use NFB::Utilities::Common qw(db_connect);
}

I'm trying the code newly-installed on a Fedora Core 6 system running
Perl 5.8.8 and it fails to compile, complaining that (in the above
example) "db_connect" is not exported by the NFB::Utilities::Common
module". It's clear that it is exported. Commenting out the offending
lines, where the module uses subroutines from itself, fixes the problem.

The "use" happens at compile time, at which point your
@EXPORT_OK is not yet set up because that happens at run time. If
I put the @EXPORT_OK assignment in a BEGIN block, then that particular
problem goes away.

That's OK: I can easily find and remove the offending lines.

Good, because I think they are conceptual nightmare. Why would a module
want to import into its own name space something which is already in
its name space to start with?
But the
code runs clean on an FC5 machine also running perl 5.8.8, and on my
Windows machine running ActiveState 5.8.8, so I'm worried that I'm
chasing a secondary error, actually caused by something else.

I get the warning on my 5.8.8 ActiveState.
Binary build 817 [257965] provided by ActiveState
http://www.ActiveState.com

Are you sure you are running the exact same code (and with it being
initially "use"d from the exact same code) in both places?

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
 
H

Henry Law

Presumably there is also a relevant part where you
put Exporter in ISA, or use base.

Yes; maybe I snipped too much, in the interests of brevity.
The "use" happens at compile time, at which point your
@EXPORT_OK is not yet set up because that happens at run time. If
I put the @EXPORT_OK assignment in a BEGIN block, then that particular
problem goes away.

Mmm, yes. But the perplexing thing is that this code (at a slightly
earlier modification level) has been running sweetly for a year now.
Good, because I think they are conceptual nightmare. Why would a module
want to import into its own name space something which is already in
its name space to start with?

There's no reason; the cause is mistakes on my part. It came about
because I develop subs in-line (at which point they do need to import
the other subs) and then move them into the package where they belong.
Sometimes I fail to delete all the "use" statements that import stuff
from the package they eventually get put into.
But the
code runs clean on an FC5 machine also running perl 5.8.8, and on my
Windows machine running ActiveState 5.8.8, so I'm worried that I'm
chasing a secondary error, actually caused by something else.

I get the warning on my 5.8.8 ActiveState.
Binary build 817 [257965] provided by ActiveState
http://www.ActiveState.com

Do you indeed? I have the same build (817) and the sample code I posted
compiles cleanly with perl -c. I sense the influence of dark matter, or
spacemen, or spies from Redmond.
Are you sure you are running the exact same code (and with it being
initially "use"d from the exact same code) in both places?

As sure as I am of anything. The code is tar'd on the FC5 machine where
it runs smoothly and is then un-tar'd onto the FC6 machine where I get
the "not exported" errors, ending up in same-named directories. But
there is always a chance, I must admit.

Thanks for trying to help. Since nobody has posted with detailed wisdom
about some other problem that is manifesting itself like this I'll just
write a little utility to whip through and remove the offending
references.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top