Old .pl modules and new .pm modules

Question

I'm new to Perl, and I'm trying to create in my head the best ways to structure a Perl program. I own Python, and I'm used to the python path from foo import bar to import functions and classes from python modules. As I understood in Perl, there are many ways to do this: .pm and .pl modules, EXPORTs and @ISA, use and require, etc., And it is not easy for beginners to get a clear idea of ​​what are the differences, advantages and disadvantages of each ( even after reading Perl and Perl).

The problem is that my current question is related to the sentence from perldoc perlmod :

Perl module files have the extension .pm. The use statement assumes this, so you do not need to specify "Module.pm" in quotation marks. This also helps to differentiate new modules from old .pl and .ph files.

What are the differences between the old .pl way to prepare modules and the new way .pm?

Are they really old and modern? (I assume this is because Perlmod is talking about this, but I would like some information about this).

Answer 1

What are the differences between the old .pl way to prepare modules and the new way .pm?

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

In older times there were no packages. One did, for example. require "open2.pl"; , which is essentially the same as the contents of the file, as in the calling script. All declared functions, all global variables become part of the script context. Or in other words: pollution of your context. Including multiple files could lead to all possible conflicts.

New modules use package to define their own context and namespace name. When use -ed from a script, new modules have the ability not to import or add anything to the immediate context of the script, thus preventing namespace pollution and potential conflicts.

Lists

@EXPORT / @EXPORT_OK are used by the standard Exporter utility module, which helps to import module functions into the calling context: so that there is no need to write the full name of the functions all the time. Lists are usually configured by the module depending on the parameter list passed to use , as in use POSIX qw/:errno_h/; . See perldoc Exporter .

@ISA is Perl's inheritance mechanism. He tells Perl that if he cannot find the function inside the current package, scan the function inside all the packages mentioned in @ISA . Simple modules often only use the import() method mentioned by Exporter (which is also well described in the same perldoc Exporter ).

Answer 2

The use and .pm function types were introduced in Perl 5, released 16 years ago next month. "Old.pl and .ph files" perlmod refers to those used with Perl 4 (and earlier). At the moment, they are interesting only to computer historians. For your purposes, just forget about the .pl libraries.

Answer 3

Reusing code by creating .pl files ("pl" actually means "Perl library") was the way it was done in Perl 4 — before we got the keywords “package” and “use”.

This is an unpleasant old way of doing things. If you come across documentation that recommends it, then this indicates that you should ignore this documentation because it is either really old or written by someone who has not been updated with Perl for more than fifteen years.

For some examples of different ways to create Perl modules in a modern way, see my answer to calling the Perl module method: it is impossible to call the "X" method on an undefined value in the line $ {SOMEFILE} $ {SOMELINE}

Answer 4

I don't know anything about .pl modules rather than they existed a while ago, nobody seems to be using them these days, so you shouldn't use them either.

Stick to pm modules, ignore @ISA right now for OOP. Export is also not so important, because you can always completely abandon your methods.

To write instead:

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(); 

To get started, 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 this without modifying your existing code.

Using loads your module and calls import, which will make any available EXPORTED available in your current package. In the example seconds, the request should be executed, which does not cause the import, but I usually use "use".