Old .pl modules versus new .pm modules

I'm a beginner in Perl and I'm trying to build in my head the best ways of structuring a Perl program. I'm proficient in Python and I'm used to the python from foo import bar way of importing functions and classes from python modules. As I understood in Perl there are many ways of doing this, .pm and .pl modules, EXPORTs and @ISAs, use and require, et开发者_运维问答c. and it is not easy for a beginner to get a clear idea of which are the differences, advantages and drawbacks of each (even after reading Beginning Perl and Intermediate Perl).

The problem stated, my current question is related to a sentence from perldoc perlmod:

Perl module files have the extension .pm. The use operator assumes this so you don't have to spell out "Module.pm" in quotes. This also helps to differentiate new modules from old .pl and .ph files.

Which are the differences between old .pl way of preparing modules and the new .pm way?

Are they really the old and the modern way? (I assume they are because Perlmod says that but I would like to get some input about this).

The use function and .pm-type modules were introduced in Perl 5, released 16 years ago next month. The "old .pl and .ph files" perlmod is referring to were used with Perl 4 (and earlier). At this point, they're only interesting to computer historians. For your purposes, just forget about .pl libraries.

Which are the differences between old .pl way of preparing modules and the new .pm way?

You can find few old modules inside the Perl's own standard library (pointed to by @INC, the paths can be seen in perl -V output).

In older times, there were no packages. One was doing e.g. require "open2.pl"; which is analogous to essentially including the content of file as it is in the calling script. All functions declared, all global variables were becoming part of the script's context. Or in other words: polluting your context. Including several files might have lead to all possible conflicts.

New modules use package keyword to define their own context and name of the namespace. When use-ed by a script, new modules have possibility to not import/add anything to the immediate context of the script thus prevent namespace pollution and potential conflicts.

@EXPORT/@EXPORT_OK lists are used by standard utility module Exporter which helps to import the module functions into the calling context: so that one doesn't have to write all the time full name of the functions. The lists are generally customized by the module depending on the parameter list passed to the use like in use POSIX qw/:errno_h/;. See perldoc Exporter for more details.

@ISA is a Perl's inheritance mechanism. It tells Perl that if it can't find a function inside of the current package, to scan for the function inside all the packages mentioned in the @ISA. Simple modules often have there only the Exporter mentioned to use its import() method (what is also well described in the same perldoc Exporter).

Reusing code by creating .pl files (the "pl" actually stands for "Perl library") was the way that it was done back in Perl 4 - before we had the 'package' keyword and the 'use' statement.

It's a nasty old way of doing things. If you're coming across documentation that recommends it then that's a strong indication that you should ignore that documentation as it's either really old or written by someone who hasn't kept up to date with Perl development for over fifteen years.

For some examples of the different ways of building Perl modules in the modern way, see my answer to Perl Module Method Calls: Can't call method “X” on an undefined value at ${SOMEFILE} line ${SOMELINE}

I don't know nothing about .pl rather modules rather than they did exist some time ago, nobody seems to use them nowadays so you proably shouldn't use them either.

Stick to pm modules, ignore @ISA right now, that's for OOP. Export isn't that important either, because you can always call your methods fully quallified.

So rather than writing this:

file: MyPkg.pm

package MyPkg;
@EXPORT = qw(func1 func2);

sub func1 { ... };
sub func2 { ... };

file: main.pl

#!/usr/bin/perl
use strict;
use warnings;

use MyPkg;

&func1();

you should, for the beginning, write that:

file: MyPkg.pm

package MyPkg;

sub func1 { ... };
sub func2 { ... };

file: main.pl

#!/usr/bin/perl
use strict;
use warnings;

use MyPkg;

&MyPkg::func1();

And later when you see which methods should really be exported you can do that without having to change your exisiting code.

The use loades your module and call import, which would make any EXPORTed subs avalable in your current package. In the seconds example a require would do, which doesn't call import, but I tend to always use 'use'.