Старые модули .pl и новые модули .pm

Question

Я новичок в Perl и пытаюсь придумать лучшие способы структурирования Perl-программы.Я опытный в Python, и я привык к способу импорта функций и классов из модулей Python Python from foo import bar.Как я понял в Perl, есть много способов сделать это, модули .pm и .pl, EXPORTs и @ISAs, использовать и требовать и т. Д., И новичку непросто понять, в чем заключаются различия,Преимущества и недостатки каждого из них (даже после прочтения Beginning Perl и Intermediate Perl).

В заявленной проблеме мой текущий вопрос связан с предложением perldoc perlmod:

Файлы модулей Perl имеют расширение .pm.Оператор use предполагает это, поэтому вам не нужно указывать «Module.pm» в кавычках.Это также помогает отличать новые модули от старых файлов .pl и .ph.

В чем различия между старым .pl способом подготовки модулей и новым .pm way?

Они действительно old и modern way?(Я предполагаю, что это потому, что Perlmod говорит, что, но я хотел бы получить некоторую информацию об этом).

Answer 1

Функции use и модули .pm были введены в Perl 5, выпущенном 16 лет назад в следующем месяце.«Старые .pl и .ph файлы», на которые ссылается perlmod, использовались с Perl 4 (и ранее).На данный момент они интересны только компьютерным историкам.Для ваших целей просто забудьте о .pl библиотеках.

Answer 2

В чем различия между старым .pl способом подготовки модулей и новым .pm способом?

Вы можете найти несколько старых модулей в собственной стандартной библиотеке Perl (на которую указывает@INC, пути можно увидеть в выводе perl -V).

В прежние времена не было пакетов.Один делал, например, require "open2.pl";, что аналогично по существу включению содержимого файла, как оно есть в вызывающем скрипте.Все функции объявлены, все глобальные переменные становятся частью контекста скрипта.Или другими словами: загрязнение вашего контекста.Включение нескольких файлов могло привести ко всем возможным конфликтам.

Новые модули используют ключевое слово package для определения собственного контекста и имени пространства имен.Когда use -ed в сценарии, новые модули имеют возможность не импортировать / добавлять что-либо в непосредственный контекст сценария, что предотвращает загрязнение пространства имен и потенциальные конфликты.

@EXPORT/ @EXPORT_OK списки используются стандартным служебным модулем Exporter, который помогает импортировать функции модуля в вызывающий контекст: чтобы не приходилось постоянно писать полное имя функции.Списки обычно настраиваются модулем в зависимости от списка параметров, передаваемого в use, как в use POSIX qw/:errno_h/;.См. perldoc Exporter для получения более подробной информации.

@ISA - это механизм наследования Perl.Он сообщает Perl, что если он не может найти функцию внутри текущего пакета, нужно выполнить поиск функции во всех пакетах, упомянутых в @ISA.В простых модулях часто используется только упомянутый Exporter для использования метода import() (что также хорошо описано в том же perldoc Exporter).

Answer 3

Повторное использование кода путем создания файлов .pl (на самом деле «pl» означает «библиотека Perl») было способом, которым это было сделано еще в Perl 4 - до того, как у нас было ключевое слово «пакет» и оператор «использование».

Это мерзкий старый способ ведения дел.Если вы сталкиваетесь с документацией, которая рекомендует это, то это явный признак того, что вы должны игнорировать эту документацию, так как она действительно старая или написана кем-то, кто не следил за развитием Perl более пятнадцати лет.

Некоторые примеры различных способов построения модулей Perl современным способом см. В моем ответе на вызовы методов модуля Perl: Не удается вызвать метод «X» для неопределенного значения в строке $ {SOMEFILE} $ {SOMELINE}

Answer 4

Я ничего не знаю о .pl, а о модулях, а не о том, что они существовали некоторое время назад, кажется, что никто не использует их в настоящее время, поэтому вам, вероятно, не следует их использовать.

Придерживайтесь модулей PM, игнорируйте @ISA прямо сейчас, это для ООП. Экспорт тоже не так важен, потому что вы всегда можете вызвать ваши методы полностью в кавычки.

Так что вместо того, чтобы писать это:

файл: MyPkg.pm

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

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

файл: main.pl

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

use MyPkg;

&func1();

для начала напишите:

файл: MyPkg.pm

package MyPkg;

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

файл: main.pl

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

use MyPkg;

&MyPkg::func1();

И позже, когда вы увидите, какие методы действительно должны быть экспортированы, вы можете сделать это без необходимости изменения существующего кода.

Использование загружает ваш модуль и вызывает импорт, что сделает любые экспортированные субпродукты доступными в вашем текущем пакете. В примере с секундами будет использоваться require, который не вызывает import, но я обычно использую «use».