Как разделить длинный код Perl на несколько файлов без слишком большого ручного редактирования? - PullRequest
0 голосов
/ 08 августа 2011

Как разделить длинный Perl-скрипт на два или более разных файла, которые могут иметь доступ к одним и тем же переменным - без необходимости переименовывать все общие переменные, например, с $count на $::count (или $main::count, что является одинаковым)?

Другими словами, какой самый лучший и простой способ разбить скрипт Perl на несколько файлов без необходимости импорта большого количества переменных / функций и / или большого количества ручного редактирования.

Я предполагаю, что это как-то связано с тем, чтобы сделать код частью того же пакета / scope / namespace, но мои эксперименты пока не увенчались успехом.

Я не уверен, что это что-то меняет, но сценарийиспользуется для целей web / CGI и будет работать в режиме mod_perl.

EDIT - Справочная информация:

Я вроде знал, что получу этот ответ.Причина, по которой я хочу разделить файл, заключается в следующем:

В настоящее время у меня есть один очень старый и очень длинный файл Perl.Я знаю, что он не следует передовым методикам Perl, но он работает .

Проблема в том, что мне нужно распределять файлы данных, которые он использует, между различными веб-серверами, прежде всего из соображений производительности.Будет один «главный» сервер и один или несколько «ведомых».

Около 20% упомянутого Perl-файла содержит общие функции, 40% имеет код, необходимый для запуска на главном сервере, и 40% наподчиненные серверы.Поэтому я хотел бы разделить код на три файла: 1. общий, 2. только главный, 3. только подчиненный.На главном сервере будут загружены 1 и 2, на ведомых - 1 и 3.

Я предполагаю, что при таком подходе будет использоваться меньше оперативной памяти и, что более важно, я минимизирую риск неправильное разделение кода (например, подчиненный процесс, вызывающий файл основных данных).Я не вижу особой необходимости в модульности, так как система работает, и код не нуждается в большом количестве изменений или обменов с другими проектами.

РЕДАКТИРОВАТЬ 2 - Решение:

Нашел решение, которое я искал здесь: http://www.perlmonks.org/?node_id=95813

В случаях, когда основной пакет находится во владении переменной, фактическое слово 'main' может быть опущено, чтобы получить что-тонапример: $ :: var

Можно обойтись без необходимости полностью квалифицировать имена переменных, когда используется строгий.Применение простого сценария vars к вашему сценарию с именами переменных в качестве аргументов поможет обойтись без явных имен пакетов.

На самом деле я закончил повторять оператор our ($count, etc...) для необходимых переменных вместо use vars ();

Дайте мне знать, если мне не хватает чего-то жизненно важного - не считая модулей!:)

@ Axeman, спасибо, я приму ваш ответ, как за ваши усилия, так и за то, что вы отправили меня в правильном направлении.

1 Ответ

5 голосов
/ 08 августа 2011

Если вы не поместите различные операторы пакета в их файлы, они будут обрабатываться так, как если бы они имели package main; вверху. Поэтому, предполагая, что сценарии используют переменные пакета, вам не нужно ничего делать. Если вы объявили их с помощью my (то есть, если они являются переменными с лексической областью), то вам необходимо убедиться, что все ссылки на переменные находятся в одном файле.

Но разделение скриптов по длине - это гнилая замена модуляции. Да, модульность помогает уменьшить длину кода, но модульность , если правильный способ уменьшить длину кода - по всем причинам, по которым вы хотели бы уменьшить длину кода, модульность делает это лучше всего.

Если нарезка файлов по длине действительно может работать для вас, то вы можете создать скрипт, подобный этому:

do '/path/to/bin/part1.pl';
do '/path/to/bin/part2.pl';
do '/path/to/bin/part3.pl';
...

Но я отчасти подозреваю, что если организация этого кода столь же плоха, как вы - что-то вроде - указываете, он может пострадать от того же изобретения, которое было изобретено в Perl. Сценарии Просто случайно (я могу ошибаться), но я думаю, вы удивитесь тому, сколько можно вырезать из длины, просто заменив более проверенные идиомы библиотеки Perl, чем for -looping и while -ing все.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...