如何为自定义Perl模块选择不与内置或CPAN包名称冲突的包名称？

我已经阅读了，但是我没有看到关于命名包的建议，这样它就不会与内置或CPAN模块/包名称冲突

过去，为了开发local Session.pm模块，我使用公司名称创建了一个本地目录，例如：

package Company::Session;

。。。和Session.pm将在Company/目录中找到

但我不喜欢这种命名惯例。我宁愿将包层次结构命名为更接近代码功能的层次结构。但CPAN通常就是这样做的

我觉得我错过了一些基本的东西。我还查看了Damian的Perl最佳实践，但可能没有找到正确的地方

有没有关于以正确的方式避免包名称空间冲突的建议

---

更新w/相关问题：如果存在包名冲突，Perl如何选择要使用的包名？谢谢大家。

为您的包选择一个您喜欢的名称，然后用谷歌搜索“perl您选择的名称”有什么不对？

如果您需要最大程度的确定性，确保您的模块名称不会与其他人的模块名称冲突，您可以从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

---

但一开始看起来确实很奇怪。

以公司名称命名内部模块并没有错；我总是这样做。我90%的代码都是在CPAN上完成的，所以它有“正常”的名称，但内部代码总是以

ClientName:：

开头

---

我相信其他人也会这样做。

名称空间

Local:：

就是为了这个目的而保留的。CPAN或core不会接受以该前缀开头的模块。或者，您可以在顶级名称中使用下划线（如

My_Corp:：Session

或仅

My_Session

）。所有带有下划线的类别也已保留。（这在“为模块选择名称”下的中提到。）

请注意，这两个保留仅适用于顶级名称。例如，有名为

Time:：Local

和

Text:：csvxs

的CPAN模块。但是

Local:：Time

和

Text_CSV:：XS

是保留名称，在CPAN上不被接受

以公司名称命名模块也可以。（好吧，除非你为一家听起来很普通的公司工作。）使用反向域名可能有点过头了，除非你打算将你的模块分发给其他人。（但在这种情况下，您可能应该注册一个普通的模块名。）

Perl如何解决冲突：

Perl在

@INC

中的目录中搜索具有指定名称的模块。找到的第一个模块就是使用的模块。因此，

@INC

中目录的顺序决定了将使用哪个模块（如果在不同位置安装了同名模块）

perl-V

将报告

@INC

的内容（优先级最高的目录列在前面）。但是在运行时也有很多方法可以操作

@INC

顺便说一句，Raku可以，甚至可以在一个程序中使用多个。这是一个不同的解决方案。

（我知道这篇文章很旧，但在过去的几个月里，我不得不整理这篇文章，我想我应该加入进来）

在工作中，我们认为“本地：：”感觉太地理化了。CompanyName：：我们也遇到了一些与开发无关的问题，我将跳过这些问题，不过我要说的是，CompanyName很长，您需要多次键入它

所以我们决定了“我们的：：”。当然，我们不是“CPAN安全的”，因为有一天我们可能想要使用带有：：前缀的CPAN模块。但是感觉很好

我们的：：Data是我们的Class：：DBI模块 我们的：：App是执行配置处理和Getopt操作的通用应用程序框架

---

阅读和键入都很好。

变量

@INC

包含一个目录列表，可以在其中查找模块。它从第一个条目开始，如果找不到请求模块，则转到下一个条目

@INC

有一个在编译perl时创建的默认值，但您可以使用环境变量更改它，并直接在

开始

块中操作

@INC

数组：

#!/usr/bin/perl

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

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

---

我正在寻找一种解决方案，以防止我的系统管理员安装一个未来的CPAN模块，然后与我的模块发生冲突…作为旁注，这正是为什么Java名称空间首先使用域名（除了内置类，它以Java.或javax开头。）。NET也有同样的问题，但是…从我所能说的来看，这是非常确定的，非常感谢。或者是项目的名称。当市场营销部决定更改名称时，请选择PITA我没有说我会这么做，只是它给了你最好的保护。当我在Capital One工作时，我们使用了CapOne:：*因为我们有理由相信不会发生冲突，但如果另一个部门在同一台机器上，并且认为同样的事情，可能会发生不好的事情。为此，我几乎认为应该将“我们的”添加到保留名称空间中。三个角色是无法击败的。可能感觉有点像我/我们的变量作用域，但是。。。也许这个比喻很恰当。一位同事告诉我，他就是这样解决这个问题的，他将本地模块目录添加为第一个@INC条目。