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

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

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

package Company::Session;

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

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

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

Какие-либо рекомендации по тому, как правильно избегать конфликтов пространства имен пакетов?

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


person Marcus    schedule 18.03.2009    source источник
comment
В качестве примечания: именно поэтому пространства имен Java создаются сначала с доменным именем (за исключением встроенных классов, которые начинаются с java. Или javax.). Хотя у .NET такая же проблема ...   -  person Powerlord    schedule 18.03.2009


Ответы (6)


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

Кстати, Raku может обрабатывать несколько модулей с одинаковыми именами от разных авторов и даже использовать более одного в одной программе. Это другое решение.

person cjm    schedule 18.03.2009
comment
Это чертовски окончательно из того, что я могу сказать, спасибо миллион. - person Marcus; 18.03.2009

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

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

person jrockway    schedule 18.03.2009
comment
Это или название проекта. PITA, когда маркетинг решает сменить название. ;) - person Schwern; 22.03.2009

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

person Nathan Stocks    schedule 18.03.2009
comment
Я ищу решение, которое помешает моему системному администратору установить будущий модуль CPAN, который затем столкнется с моим ... - person Marcus; 18.03.2009

Переменная @INC содержит список каталогов, в которых нужно искать модули. Он начинается с первой записи, а затем переходит к следующей, если не находит модуль запроса. @INC имеет значение по умолчанию, которое создается при компиляции perl, но вы можете изменить его с помощью PERL5LIB < / a> переменная среды, 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:)
person Chas. Owens    schedule 02.04.2009
comment
Вот как один из сотрудников сказал мне, что он решает эту проблему, добавляя свой локальный каталог модулей в качестве первой записи @INC. - person Marcus; 02.04.2009

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

  • Com :: Example :: Biz :: FindCustomers
  • Com :: Example :: IT :: ParseLogs
  • Com :: Example :: QA :: TestServer

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

person Chas. Owens    schedule 18.03.2009
comment
Я не сказал, что сделаю это, просто это дало вам лучшую защиту. Когда я работал в Capital One, мы использовали CapOne :: *, потому что были достаточно уверены, что конфликта не будет, но если бы другой отдел был на той же машине и думал то же самое, могли случиться плохие вещи. - person Chas. Owens; 22.03.2009

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

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

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

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

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

person RickMeasham    schedule 02.04.2009
comment
Я почти думаю, что для этой цели в зарезервированное пространство имен следует добавить «Наш». Трех персонажей невозможно победить. Может показаться, что это немного похоже на мою / нашу область видимости переменных, но ... может быть, метафора достаточно хороша. - person Marcus; 02.04.2009