Как выбрать имя пакета для настраиваемого модуля Perl, который не сталкивается с именами встроенных или CPAN-пакетов?

Я прочитал perldoc на модулях, но я не вижу рекомендации по именованию пакета, чтобы он не сталкивался со встроенным или имена модулей CPAN/пакетов.

В прошлом, чтобы создать локальный модуль Session.pm, я создал локальный каталог, используя имя моей компании, например:

package Company::Session;

... и Session.pm можно найти в каталоге Company/.

Но я просто не поклонник этого соглашения об именах. Я бы скорее назвал иерархию пакетов ближе к функциональности кода. Но как это делается на CPAN в целом...

Я чувствую, что мне не хватает чего-то фундаментального. Я также посмотрел в Damian Perl Best Practices, но я, возможно, не искал в нужном месте...

Любые рекомендации по предотвращению столкновений пространства имен пакетов правильным способом?

Обновление с связанным с ним вопросом. Если существует конфликт имен пакетов, как Perl выбирает, какой из них использовать? Спасибо всем.

Ответ 1

Пространство имен Local:: зарезервировано для этой цели. Модуль, начинающийся с этого префикса, не будет принят в CPAN или в ядре. Кроме того, вы можете использовать символ подчеркивания в имени верхнего уровня (например, My_Corp::Session или просто My_Session). Также были зарезервированы все категории с подчеркиванием. (Это упоминается в perlmodlib в разделе "Выберите имя для модуля".)

Обратите внимание, что обе эти оговорки относятся только к имени верхнего уровня. Например, существуют CPAN-модули с именем Time::Local и Text::CSV_XS. Но Local::Time и Text_CSV::XS являются зарезервированными именами и не будут приняты в CPAN.

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

Как Perl разрешает конфликт:

Perl ищет каталоги в @INC для модуля с указанным именем. Первый найденный модуль - тот, который используется. Таким образом, порядок каталогов в @INC определяет, какой модуль будет использоваться (если у вас есть модули с тем же именем, установленным в разных местах).

perl -V сообщит о содержании @INC (сначала будут указаны каталоги с наивысшим приоритетом). Но есть много способов манипулировать @INC во время выполнения.

BTW, Perl 6 сможет обрабатывать несколько модулей с одинаковым именем разными авторами и даже использовать более одного в одном программа. Но это не решит вашу проблему.

Ответ 2

Нет ничего плохого в том, чтобы называть ваши внутренние модули после вашей компании; Я всегда это делаю. 90% моего кода заканчивается на CPAN, поэтому у него есть "обычные" имена, но внутренний материал всегда начинается с ClientName::.

Я уверен, что все остальные тоже делают это.

Ответ 3

Что плохого в том, чтобы просто выбрать имя для своего пакета, который вам нравится, а затем переигрывать "perl the-name-you-selected"?

Ответ 4

Переменная @INC содержит список каталогов, в которых нужно искать модули. Он начинается с первой записи, а затем переходит к следующей, если он не находит модуль запроса. @INC имеет значение по умолчанию, которое создается при компиляции perl, но вы можете изменить его с помощью переменной PERL5LIB, lib pragma и непосредственно манипулировать массивом @INC в блоке BEGIN:

#!/usr/bin/perl

BEGIN {
    @INC = (); #no modules can be found
}

use strict; #error: Can't locate strict.pm in @INC (@INC contains:)

Ответ 5

Если вам нужен максимальный уровень уверенности в том, что имя вашего модуля не будет конфликтовать с кем-то другим, вы можете взять страницу из книги Java: назовите модуль с именем домена компании. Поэтому, если вы работаете для примера, Inc. и их доменного имени example.com, вы бы назвали ваш HTML-парсерный модуль Com:: Example:: HTML:: Parser или Example:: Com:: HTML:: Parser. Преимущество первого заключается в том, что если у вас есть несколько субъединиц, все они могут иметь собственное пространство имен, но модули все равно будут сортироваться вместе:

Com:: Пример:: Biz:: FindCustomers
Com:: Пример:: IT:: ParseLogs
Com:: Пример:: QA:: TestServer

но сначала он выглядит нечетно.

Ответ 6

(Я знаю, что это сообщение устарело, но, поскольку мне пришлось разбираться в последние несколько месяцев, я думал, что буду взвешивать)

На работе мы решили, что "Local::" чувствовал себя слишком географически. CompanyName:: были проблемы для нас тоже, которые не связаны с развитием, я пропущу их, хотя я скажу, что CompanyName длиннее, когда вам приходится вводить его десятки раз.

Итак, мы остановились на "Наше". Конечно, мы не "CPAN Safe", так как может быть день, когда мы хотим использовать модуль CPAN с префиксом Our::. Но это приятно.

Наш:: Data - наш модуль Class:: DBI Our:: App - это наша универсальная инфраструктура приложений, которая поддерживает конфигурацию и Getopt.

Приятно читать и красиво печатать.