Is it okay to use modules from within subroutines?

问题:

Recently I start playing with OO Perl and I've been creating quite a bunch of new objects for a new project that I'm working on. As I'm unfamilliar with any best practice regarding OO Perl and we're kind in a tight rush to get it done :P

I'm putting a lot of this kind of code into each of my function:

sub funcx{
    use ObjectX; # i don't declare this on top of the pm file 
                 # but inside the function itself
    my $obj = new ObjectX;
}

I was wondering if this will cause any negative impact versus putting on the use Object line on top of the Perl modules outside of any function scope.

I was doing this so that I feel it's cleaner in case I need to shift the function around.

And the other thing that I have noticed is that when I try to run a test.pl script on the unix server itself which test my objects, it slow as heck. But when the same code are run through CGI which is connected to an apache server, the web page doesn't load as slowly.

回答1:

Where to put use?

use occurs at compile time, so it doesn't matter where you put it. At least from a purely pragmatic, 'will it work', point of view. Because it happens at compile time use will always be executed, even if you put it in a conditional. Never do this: if( $foo eq 'foo' ) { use SomeModule }

In my experience, it is best to put all your use statements at the top of the file. It makes it easy to see what is being loaded and what your dependencies are.

---

Update:

As brian d foy points out, things compiled before the use statement will not be affected by it. So, the location can matter. For a typical module, location does not matter, however, if it does things that affect compilation (for example it imports functions that have prototypes), the location could matter.

Also, Chas Owens points out that it can affect compilation. Modules that are designed to alter compilation are called pragmas. Pragmas are, by convention, given names in all lower-case. These effects apply only within the scope where the module is used. Chas uses the integer pragma as an example in his answer. You can also disable a pragma or module over a limited scope with the keyword no.

use strict;
use warnings;

my $foo;
print $foo;  # Generates a warning

{   no warnings 'unitialized`;  # turn off warnings for working with uninitialized values.

    print $foo;  # No warning here
}
print $foo; # Generates a warning

---

Indirect object syntax

In your example code you have my $obj = new ObjectX;. This is called indirect object syntax, and it is best avoided as it can lead to obscure bugs. It is better to use this form:

my $obj = ObjectX->new;

Why is your test script slow on the server?

There is no way to tell with the info you have provided.

But the easy way to find out is to profile your code and see where the time is being consumed. NYTProf is another popular profiling tool you may want to check out.

Best practices

Check out Perl Best Practices, and the quick reference card. This page has a nice run down of Damian Conway's OOP advice from PBP.

Also, you may wish to consider using Moose. If the long script startup time is acceptable in your usage, then Moose is a huge win.

回答2:

question 1

It depends on what the module does. If it has lexical effects, then it will only affect the scope it is used in:

my $x;
{
    use integer;
    $x = 5/2; #$x is now 2
}
my $y = 5/2; #$y is now 2.5

If it is a normal module then it makes no difference where you use it, but it is common to use all of those modules at the top of the program.

question 2

Things that can affect the speed of a program between machines

1. speed of the processor
2. version of modules installed (some modules have XS versions that are much faster)
3. version of Perl
4. number of entries in PERL5LIB
5. speed of the drive

回答3:

daotoad and Chas. Owens already answered the part of your question pertaining to the position of use statements. Let me remark on something else here:

I was doing this so that I feel it's cleaner in case I need to shift the function around.

Personally, I find it much cleaner to have all the used modules in one place at the top of the file. You won't have to search for use statements to see what other modules are being used and a quick glance will tell you what is being used and even what is not being used.

Regarding your performance problem: with Apache and mod_perl the Perl interpreter will have to parse and compile your used modules only once. The next time the script is run, execution should be much faster. On the command line, however, a second run doesn't get this benefit.