Question

我们是大型，复杂的Perl软件产品的作者。一些代码位于可执行文件（网络守护程序）中，而某些则位于Perl库中（.pm文件）。我们的一些客户希望通过使用自己的代码覆盖我们的Perl'sub xxx {}'函数来定制他们的系统。当我们在另一个库中调用一个函数时，这是非常简单的-将/ usr / local / lib / our_product放在@INC中，他们可以在其中放置自定义代码。这样做有两个问题：

他们创建的自定义文件需要具有其要覆盖的.pm文件中的所有功能。如果缺少任何内容，Perl将在我们提供的默认.pm文件中找不到它们。
Perl始终在@INC之前检查本地文件。这样可以防止其自定义.pm文件覆盖同一文件中的函数调用。

有没有解决这些问题的方法？

Answer 1

对遗留代码执行此操作后，我创建了一个具有不同名称的软件包，该软件包将首先加载供应商软件包，然后允许覆盖：

 package Local::Overrides;
 use Vendor::Real::Name;
 use Vendor::Other::Name;


 package Vendor::Real::Name {
     no warnings 'redefine';

     sub new_definition {

          }
     };

 package Vendor::Other::Name {
     no warnings 'redefine';

     sub new_definition {

          }
     };

1;

然后，您将分发一个同名的空模块，每个脚本将始终加载该模块：

package Local::Overrides;

1;

我在Effective Perl Programming中介绍了这类内容。

还有很多其他技巧，但是在不了解您的体系结构细节的情况下，我没有什么可推荐的。

Answer 2

确实没有必要将其自定义代码放入与软件包名称匹配的文件中，从而替换或与从@INC进行加载进行协作。您可以只是安排自定义代码从另一个仍修改原始程序包的文件中加载。当然，这必须在从该软件包中进行任何导入之前发生，并且您将要关闭此类文件中的redefine警告。

# Whatever.pm
package Some::Module;
use strict;
use warnings;
no warnings 'redefine';
sub foo { ... }

重写甚至可以利用Class::Method::Modifiers，即使不涉及任何类或方法，该here仍可以使用包装器替换子对象。

use Class::Method::Modifiers;
around 'Some::Module::foo' => sub { ... };

如果您真的不想以任何方式修改现有文件，最大的麻烦可以是App::MyPerl或this所描述的sitecustomize，这是该版本的重点。 / p>

在@INC中高级搜索功能

2 个答案: