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

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?

--

Henry Law Manchester, England

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

Henry Law wrote:
> 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

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

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

Henry Law wrote:
> 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.

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

xhoster@gmail.com wrote:

>> 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.

Yes; maybe I snipped too much, in the interests of brevity.

>
>> # ... 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);
>> }

> 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.

>> 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?

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.

> Xho

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.

--

Henry Law Manchester, England