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

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

27 голосов
/ 18 марта 2009

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

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

package Company::Session;

... и файл Session.pm будет найден в каталоге Company /.

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

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

Есть ли какие-либо рекомендации о том, как избежать коллизий пространства имен пакетов?

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

Ответы [ 6 ]

38 голосов
/ 18 марта 2009

Пространство имен 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 и во время выполнения.

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

8 голосов
/ 18 марта 2009

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

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

2 голосов
/ 02 апреля 2009

Переменная @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:)
2 голосов
/ 18 марта 2009

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

1 голос
/ 02 апреля 2009

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

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

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

Наши :: Данные - это наш класс :: DBI модуль Our :: App - это наша универсальная прикладная среда, которая выполняет обработку конфигурации и Getopt

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

1 голос
/ 18 марта 2009

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

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

но поначалу это выглядит странно.

...