Аз съм начинаещ в Perl и се опитвам да изградя в главата си най-добрите начини за структуриране на програма на Perl. Владея Python и свикнах с python from foo import bar начин за импортиране на функции и класове отмодули на python. Както разбрах в Perl, има много начини да направите това, .pm и .pl модули, EXPORT и @ISA, използване и изискване и т.н. и за начинаещи не е лесно да добие ясна представа кои са разликите, предимства и недостатъци на всеки (дори след четене Beginning Perl и Intermediate Perl).
Посоченият проблем, настоящият ми въпрос е свързан с изречение от perldoc perlmod:
Модулните файлове на Perl имат разширение .pm. The
useоператор приема това, така че не е нужно изписвайте „Module.pm“ в кавички. Това също помага да се разграничат нови модули от стари .pl и .ph файлове.
Кои са разликите между стар .pl начин за подготовка на модули и нов .pm начин?
Наистина ли са стар и модерен начин? (Предполагам, че са, защото Perlmod казва това, но бих искал да получа малко информация за това).
Отговори:
4 за отговор № 1Кои са разликите между стария .pl начин за подготовка на модули и новия .pm начин?
Можете да намерите няколко стари модула в собствената стандартна библиотека на Perl (посочена от @INC, пътеките могат да се видят в perl -V изход).
В по-стари времена нямаше пакети. Един правеше напр. require "open2.pl"; което е аналог на по същество включителносъдържанието на файла, както е в извикващия скрипт. Всички декларирани функции, всички глобални променливи стават част от контекста на скрипта. Или с други думи: замърсяване на вашия контекст. Включването на няколко файла може да доведе до всички възможни конфликти.
Използване на нови модули package ключова дума, за да дефинират техния собствен контекст и име на пространството от имена. Кога use-под скрипт, новите модули имат възможност да не импортират / добавят нищо в непосредствения контекст на скрипта, като по този начин предотвратяват замърсяването на пространството от имена и потенциални конфликти.
@EXPORT/@EXPORT_OK списъците се използват от стандартния полезен модул Exporter което помага да се импортират функциите на модула вконтекстът на извикване: така че човек не трябва да пише през цялото време пълното име на функциите. Списъците обикновено се персонализират от модула в зависимост от списъка с параметри, предаден на use както в use POSIX qw/:errno_h/;, виждам perldoc Exporter за повече информация.
@ISA е механизъм за наследяване на Perl. Той казва на Perl, че ако не може да намери функция вътре в текущия пакет, да сканира за функцията във всички пакети, споменати в @ISA. Обикновените модули често имат само Exporter споменат да използва своя import() метод (което също е добре описано в същия perldoc Exporter).
8 за отговор № 2
Най- use функция и .pmмодули от типа бяха представени в Perl 5, пуснатПреди 16 години следващия месец. "Старите .pl и .ph файлове", за които се отнася perlmod, са били използвани с Perl 4 (и по-рано). В този момент те са интересни само за компютърни историци. За целите ви просто забравете .pl библиотеки.
3 за отговор № 3
Повторното използване на кода чрез създаване на .pl файлове („pl“ всъщност означава „библиотека Perl“) беше начинът, по който беше направено още в Perl 4 - преди да имаме ключовата дума „package“ и израза „use“.
Това е неприятен стар начин за правене на нещата.Ако попадате на документация, която го препоръчва, тогава това е силна индикация, че трябва да пренебрегнете тази документация, тъй като тя е наистина стара или е написана от някой, който не е бил в течение с развитието на Perl повече от петнадесет години.
За някои примери за различните начини за изграждане на Perl модули по модерен начин вижте отговорът ми на Perl Module Метод призовава: Не мога да извикам метод “X” на неопределена стойност на $ {SOMEFILE} ред $ {SOMELINE}
1 за отговор № 4
Не знам нищо за модулите .pl, а по-скоро за модулите, отколкото те са съществували преди време, в днешно време изглежда никой не ги използва, така че вие вероятно не бива да ги използвате.
Придържайте се към модулите pm, игнорирайте @ISA точно сега, това е "за OOP. Експортът не е толкова важен, защото винаги можете да извикате вашите методи напълно квалифицирани.
Така че вместо да пишете това:
файл: 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, който не извиква импортиране, но обикновено използвам "use".