Perl - 重新定义子例程

Question

我之前曾问过这个问题，或者搜索过并看到其他人问过 - 为什么我收到警告“Subroutine mySub redefine at ../lib/Common.pm line x”？并且您总是会得到答案您在同一代码中声明了两次 sub。我创建了这个测试包：

整个文件 ---------------

package MyCommonPkg;

use strict;

sub thisSubroutineIsNotDefinedAnywhereElse{
}

1;

整个文件 ---------------

我从 perl 脚本中使用这个包，它使用其他包，也使用这个包，我收到警告：

Subroutine ThisSubroutineIsNotDefinedAnywhereElse redefine at ../lib/MyCommonPkg.pm line 19.

我保证我没有在其他地方声明这个子程序。那么这是由循环引用引起的吗？我该如何追踪此警告的原因并进行修复？

Answer 1

你有依赖循环吗？如果 Perl 开始编译你的脚本并遇到这样的行：

use PackageA;

Perl 暂停编译你的脚本；找到 PackageA.pm 并开始编译它。如果遇到这样一行：

use PackageB;

Perl 暂停 PackageA 的编译；找到 PackageB.pm 并开始编译它。通常情况下，这会成功完成，Perl 将返回完成编译 PackageA，当成功完成时，它将返回编译脚本，当成功完成时，它将开始执行编译后的操作码。

但是，如果 PackageB.pm 包含这一行：

use PackageA;

您可能认为它不会执行任何操作，因为 Perl 已经处理了 PackageA.pm，但问题是它尚未完成。所以Perl会暂停PackageB的编译，并从头开始重新编译PackageA.pm。这可能会触发您看到的有关 PackageA 中的子例程被重新定义的消息。

作为一般规则，两个包不应同时相互依赖。然而，有时循环更难定位，因为它是由第三个包引起的。

Answer 2

当不同包中有两个同名的子例程时，您应该看到此警告（当启用警告时）为“子例程新重新定义......”。
简单的原因（这与 Grant McLean 所说的非常接近，但仍然不完全）是你必须让你的包跳过编译阶段并 make then require。这样，Perl 命名空间管理器在编译时就不会发现任何此类具有相同名称的冲突符号，并且如果您的模块没有任何错误，它们之后也会正常工作。

只需确保您实现

require 模块即可；

声明而不是

使用Module；

您不应再看到此警告。

Answer 3

如果您使用的系统具有不区分大小写的文件系统（Windows，通常是 OSX），并且您在一个文件中使用 Common，并在另一个文件中使用 common，你可能会导致这样的问题。

Answer 4

这听起来像是循环依赖引起的问题。以下是如何追踪它。如果您的问题类如下所示：

package AlientPlanet;
use Dinosaurs;
sub has_dinosaurs {...}
1;

然后将示例更改为如下所示：

package AlienPlanet;
sub has_dinosaurs {...}     # <-- swap
use Dinosaurs;              # <-- swap
1;

现在使用 Carp 编译代码::Always 像这样：

⚡ perl -MCarp::Always -c lib/AlienPlanet.pm                                                                                                            
Subroutine has_dinosaurs redefined at lib/AlienPlanet.pm line 4.
    require AlienPlanet.pm called at lib/Dinosaurs.pm line 4
    Dinosaurs::BEGIN() called at lib/AlienPlanet.pm line 4
    eval {...} called at lib/AlienPlanet.pm line 4
    require Dinosaurs.pm called at lib/AlienPlanet.pm line 5
    AlienPlanet::BEGIN() called at lib/AlienPlanet.pm line 4
    eval {...} called at lib/AlienPlanet.pm line 4
lib/AlienPlanet.pm syntax OK

现在您有了堆栈跟踪，您可以看到循环在哪里。快速但肮脏的解决方案是在 Dinosaurs.pm 中使用 Class::Load 。

如需更详细的解释，请尝试我的博客文章。

Answer 5

您是否有机会在网络服务器上将其作为 cgi 脚本运行？

我发现我需要重新启动网络服务器才能解决此警告。

Answer 6

看一下程序 package MyCommonPkg.pm 并看看它说了什么。有这样的东西吗？

package MyCommonPkg;

use Exporter qw(import);   #  Might be "require" and not "use"
our @EXPORT = qw(thisSubroutineIsNotDefinedAnywhereElse);

语法可能有点不同。您应该看到的主要内容是 package 语句，它使用 Exporter 并且 @EXPORT 数组中包含您的子例程的名称。

发生的事情是命名空间冲突。您的包定义的子例程与您定义的子例程相同。

为了防止这种情况发生，Perl 使用命名空间。默认情况下，您的命名空间是 main。但是，包应该使用 package 命令定义它们自己的单独同名对象。

子例程或变量的完整命名空间是命名空间后跟双冒号，然后是子例程或变量名称。例如，如果您查看 File::Find，您将看到对变量的引用$File::Find::name 和 $File::Find::dir。这些是 File::FindFile/Find.pm 包内的变量 $name 和 $dir > 命名空间。

为了让您更轻松，包可以将其变量和子例程导出到您的main命名空间中。例如，如果我使用 File::Copy，O 可以这样做：

...
use File::Copy
...
copy ($file, $to_dir);

而不是：

...
use File::Copy
...
File::Copy::copy ($file, $to_dir);

如果您查看File/Copy.pm，您将看到以下内容：

package File::Copy;
...
our(@ISA, @EXPORT, @EXPORT_OK, $VERSION, $Too_Big, $Syscopy_is_copy);
...
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(copy move);

包 File::Copy; 定义了一个命名空间。 require Exporter; 和 @ISA = qw(Exporter) 允许包将子例程和变量导出到 main 命名空间中。 @EXPORT 会自动将 copy 和 move 子例程导入到 main 命名空间中，而无需告诉您任何信息。 strong>无论您是否想要它们！

最后一点非常重要。现在使用 @EXPORT 被认为是不礼貌。相反，您应该使用@EXPORT_OK，它要求您列出要使用的子例程。更现代的软件包如 Scalar::Util 可以做到这一点。

有几件事。首先，您的 MyCommonPkg 是否有 package MyCommonPkg; 语句。如果没有，应该如此。这可以防止包子例程和变量以令人讨厌的方式影响您的程序。然后，您可以使用@EXPORT或@EXPORT_OK。

如果 MyCommonPkg 确实有 package 语句，它是否使用 @EXPORT？如果是这样，您可以通过多种方法避免此问题：

• 忽略警告。这只是一个警告。由于您知道您正在重新定义子例程，并且您想要使用您对子例程的定义，因此请忽略它。

您可以执行此操作以在重新定义子例程时关闭警告：

use MyCommonPkg;

no warnings qw(redefine);
sub thisSubroutineIsNotDefinedAnywhereElse {
   ...
}
use warnings qw(redefine);

• 使用 require MyCommonPkg; 而不是 use MyCommonPkg;。这将阻止将任何子例程或变量导入您的命名空间，包括您想要使用的子例程或变量。假设 MyCommonPkg 定义了四个子例程：thisSubroutineIsNotDefinedAnywhereElse、foo、bar 和 barfoo 。使用这些子例程中的任何一个。

你需要这样做：

my $answer = MyCommonPkg::foo( $input );

不好玩。

• 为您的子例程使用另一个名称。应该已经记录了该子例程是在 MyCommonPkg 中定义的，如果您想使用 MyCommonPkg，则不应使用导出的子例程名称。

• 最后，如果 MyCommonPkg 相当新，并且未在数十个程序中使用，请使用 @EXPORT_OK 而不是 @EXPORT，并确保所有使用 MyCommonPkg 的程序都被修改为导出它们想要的子例程：

像这样：

use MyCommonPkg qw(foo bar);

在这种情况下，仅导出子例程foo和bar。子例程 thisSubroutineIsNotDefinedAnywhereElse 和 barfoo 不会导出到您的环境中。

Answer 7

我尝试使用“package Common.pm”作为包名称。编译器给了我错误。非常友善吧？你使用什么版本的 Perl？我在5.10.0和5.12.1上尝试过。

即使您可以编译，删除 .pm 文件也是一个好习惯。例如;

文件：some_package.pm；

package some_package;
use strict;

sub yadayadayada { ... }

1;

Answer 8

确保您没有忘记模块末尾的这一行：

1;

我知道它已包含在此处的一些示例中，但我提到它是因为它很容易被忽视，并且就我而言，这是错误的唯一原因！

Answer 9

我也遇到了同样的问题；这是因为程序使用了模块，并且子程序同时存在于程序和perl模块中；