|
Posted by Henry Law on January 27, 2008, 6:55 pm
Please log in for more thread options xhoster@gmail.com wrote:
>> package NFB::Utilities::Common;
>> # ...
>> our @EXPORT_OK = ( @{ $EXPORT_TAGS}, 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
| 
XML Sitemap