Own module needs loaded module from main script

[Bart Van der Donck]

Hello,

My main program calls this module:

use DBI;

Then it calls another module (one of myself), using this code:

use lib '/path/to/my/module/';
use NameOfMyModule;

Inside NameOfModule.pm, I want to execute commands that need the
previously loaded DBI.pm. However it fails, saying that DBI.pm isn't
loaded. Which could be solved quickly by invoking DBI.pm again from
within NameOfModule.pm.

This works fine. But the waste of memory is considerable because I
have tens of own modules like NameOfMyModule that are invoked from the
main program. Most of them need DBI.

I looked at some stuff to solve this, looks as if something like
Exporter.pm is available for this kind of things. But then I would
need to load Exporter from within all my own modules. Which would be
about the same as loading DBI each time.

Any hints?

Thank you,
Bart

 

[Gunnar Hjalmarsson]

My main program calls this module:

use DBI;

Then it calls another module (one of myself), using this code:

use lib '/path/to/my/module/';
use NameOfMyModule;

Inside NameOfModule.pm, I want to execute commands that need the
previously loaded DBI.pm. However it fails, saying that DBI.pm
isn't loaded.

Is that really what it says? I doubt it.

You need to distinguish between loading a module and importing
possible symbols into a package. You should be able to access its
functions and possible global variables by calling them with their
fully qualified names.

Which could be solved quickly by invoking DBI.pm again from within
NameOfModule.pm.

This works fine. But the waste of memory is considerable because I
have tens of own modules like NameOfMyModule that are invoked from
the main program. Most of them need DBI.

Misconception. What happens if you include "use DBI;" in
NameOfModule.pm as well is that you import possible symbols that are
exported by default. DBI.pm is not compiled once again.

Please study "perldoc perlmod".

 

[ctcgag]

Hello,

My main program calls this module:

use DBI;

Then it calls another module (one of myself), using this code:

use lib '/path/to/my/module/';
use NameOfMyModule;

Inside NameOfModule.pm, I want to execute commands that need the
previously loaded DBI.pm. However it fails, saying that DBI.pm isn't
loaded.

What, exactly, fails and says that? If you only use DBI in an OO way,
you should not have a problem. If you don't use DBI in an OO way, you
should start.

Which could be solved quickly by invoking DBI.pm again from
within NameOfModule.pm.

This works fine. But the waste of memory is considerable because I
have tens of own modules like NameOfMyModule that are invoked from the
main program. Most of them need DBI.

I wouldn't worry about the memory wasted (it would only be the neglible
amount of memory needed to import variables), but if each module is opening
its own connection to the database, that is potentially wasteful (and
buggy).

Xho

 

[Bart Van der Donck]

Thanks to both posters.

I was not entirely right about the error report. Script didn't say
that the module was not loaded (however it was the cause why it
failed).

What happens if you include "use DBI;" in
NameOfModule.pm as well is that you import possible symbols that are
exported by default. DBI.pm is not compiled once again.

OK that's great. That solves my original concern about the waste of
memory and compiling the same module again (as I thought it would).

I did some further research and come to odd results.

-------------------------------------
This is always present in main script
-------------------------------------
use DBI;
use lib '/path/to/my/own/modules/';
use DBconf; # own module
&DBconf:Bvars(); # returns hash with configuration values
use MyModule; # own module


----------------------
Case 1: MyModule has:
----------------------
use DBconf;
&DBconf:Bvars();

Result of case 1: script OK.


----------------------
Case 2: MyModule has:
----------------------
&DBconf:Bvars();

Result of case 2: Error: Can't call method "prepare" on an undefined
value at /some/path/MyModule.pm line 22.
Line 22 is the first connection string towards MySQL. DBconf:Bvars()
should have given the connection parameters, but obviously it returned
empty values. It probably needs "use DBconf;" first, I'ld say.


----------------------
Case 3: MyModule has:
----------------------
use DBconf;

Result of case 3: script OK
Odd, I didn't even invoke DBconf:Bvars() !


--------------------------------------
Case 4: No modules invoked by MyModule
--------------------------------------

Result of case 4: Error: Can't call method "prepare" on an undefined
value at /some/path/MyModule.pm line 22.
I believe the situation is the same as in case 2.


---

It's unclear for me to draw a line in these results. Seems that I need
to invoke "use DBconf;", but without need to call sub
"&DBconf:Bvars();" (?)

Following calls apparently don't need to take place (script works fine
with or without these):
use DBI;
use lib '/path/to/my/own/modules/';
....which is not very logical, presuming that I do need "use DBconf;".

I am thinking about the construction of my module DBconf and the way
it exports its variables. AFAIK, this is all pretty default (shortened
code):

package DBconf;
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(%CONFIG);
@EXPORT_OK = qw(%CONFIG);
sub DBvars
{ %CONFIG = (first=>"1",second=>"2"); }
1;

Best regards
Bart

 

[Gunnar Hjalmarsson]

I did some further research and come to odd results.

If you think those results are odd, you haven't spent very long time
with studying "perldoc perlmod", have you? It's good that you
experiment, but you do need to read the docs, too.

Also, you should include

use strict;
use warnings;

in the beginning of every script / module. Doing so will make Perl
help you understand what's going on.

Anyway, I have inserted a couple of comments below.

That loads the module *and* imports the %CONFIG symbol to package
main, since %CONFIG is included in the @EXPORT array.

&DBconf:Bvars(); # returns hash with configuration values

A hash with the fully qualified name %DBconf::CONFIG is created, but
the hash is not *returned* by the subroutine.

use MyModule; # own module

----------------------
Case 1: MyModule has:
----------------------
use DBconf;
&DBconf:Bvars();

Result of case 1: script OK.

----------------------
Case 2: MyModule has:
----------------------
&DBconf:Bvars();

Result of case 2: Error: Can't call method "prepare" on an undefined
value at /some/path/MyModule.pm line 22.
Line 22 is the first connection string towards MySQL. DBconf:Bvars()
should have given the connection parameters, but obviously it returned
empty values. It probably needs "use DBconf;" first, I'ld say.

Not necessarily. But at line 22 you are apparently calling the %CONFIG
hash without using its fully qualified name, while the %CONFIG symbol
has not been imported into package MyModule.

To possible solutions, besides including "use DBconf;" in MyModule.pm:

1) Always call the %CONFIG hash with its fully qualified name, or

2) Include

BEGIN { import DBconf }

in the beginning of MyModule.pm.

----------------------
Case 3: MyModule has:
----------------------
use DBconf;

Result of case 3: script OK
Odd, I didn't even invoke DBconf:Bvars() !

Why would that be odd? The hash was created when the DBvars() function
was called from the main script. Why would it need to be created again?