When to use 'use' for accessing modules?

[Chris Allen <ch...@cjx.com>]

I have a modperl site that accesses a number of modules. 
In my startup.pl I have:


#!/usr/bin/perl -w
use strict;
use lib('/path/to/my/installation'); # 'site' directory is here

use Apache::DBI;
use Apache::StatINC;
use site::customers;
use site::orders;
use site::products;
use site::base;

1;


None of the modules exports *any* symbols at all - all are called in 
the form:

$product=site::products->new(23);
$product->get('price');



First question:

If site::products calls functions from site::customers, do I need
a 'use site::customers' in site::products, when I have already
done a 'use' in my startup.pl?


Second question:

site::products contains the line:

@ISA=('site::base'); 

so that methods from site::base can be overridden in site::products.

Do I need a 'use site::base' in site::products for this to work 
correctly?



Third (unrelated) question.

Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
in httpd.conf?



-----------------------

Experience has shown that I *don't* need the 'use' statements anywhere
other than startup.pl - but I am not sure why, and would find some pointers
to a discussion of this very useful. I would also be interested to know that
if the 'use' statements *are* unnecessary, does including them add any extra
overhead of processing/memory??

Many thanks,


Chris Allen.

Re: When to use 'use' for accessing modules?

[Perrin Harkins <pe...@elem.com>]

Steve Piner wrote:
> 
> Perrin Harkins wrote:
> 
> > Chris Allen wrote:
> [...]
> > > Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
> > > in httpd.conf?
> >
> > Yes.
> 
> Are you sure? I experimented a few months ago, and found that
> $ENV{foo}='bar'; would only last in each child until the first request
> of the child completed.

You may be right.  Depends on the setting of PerlSetupEnv, I think.
- Perrin

Re: When to use 'use' for accessing modules?

[Steve Piner <st...@marketview.co.nz>]

Perrin Harkins wrote:

> Chris Allen wrote:
[...]
> > Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
> > in httpd.conf?
> 
> Yes.

Are you sure? I experimented a few months ago, and found that
$ENV{foo}='bar'; would only last in each child until the first request
of the child completed.

Steve

-- 
Steve Piner
Web Applications Developer
Marketview Limited
http://www.marketview.co.nz

Re: When to use 'use' for accessing modules?

[Perrin Harkins <pe...@elem.com>]

Chris Allen wrote:

> If site::products calls functions from site::customers, do I need
> a 'use site::customers' in site::products, when I have already
> done a 'use' in my startup.pl?


No, but I always do.  It's good documentation, to remind you that if you 
ever ran this code outside of mod_perl it would be necessary to have 
that 'use' in place.


> site::products contains the line:
> 
> @ISA=('site::base'); 
> 
> so that methods from site::base can be overridden in site::products.
> 
> Do I need a 'use site::base' in site::products for this to work 
> correctly?


Only if site::base has not been loaded already, but I always do it 
anyway, for the same reason as above.


> Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar
> in httpd.conf?


Yes.


> Experience has shown that I *don't* need the 'use' statements anywhere
> other than startup.pl - but I am not sure why, and would find some pointers
> to a discussion of this very useful.


You don't need them because the modules they would load are already loaded.

> I would also be interested to know that
> if the 'use' statements *are* unnecessary, does including them add any extra
> overhead of processing/memory??


There is a very fast check that happens once when the module containing 
the 'use' is called.  It checks to see if the used module is already 
loaded (i.e. if it is in %INC).  It also calls the used module's export 
function, unless you pass an empty list:

use Foo ();

You should avoid importing symbols all over the place, as explained in 
the Guide, but otherwise there is no significant overhead from having 
use statements all over the place.

- Perrin