2010-01-21 34 views

回答

8

已经有standard Config module,所以选择一个不同的名字。

假设你有MyConfig.pm包含以下内容:

package MyConfig; 

our $Foo = "bar"; 

our %Baz = (quux => "potrzebie"); 

1; 

然后其他模块可以使用它作为

#! /usr/bin/perl 

use warnings; 
use strict; 

use MyConfig; 

print "Foo = $MyConfig::Foo\n"; 

print $MyConfig::Baz{quux}, "\n"; 

如果你不想完全限定的名称,然后使用标准Exporter模块。

添加三行MyConfig.pm

package MyConfig; 

require Exporter; 
our @ISA = qw/ Exporter /; 
our @EXPORT = qw/ $Foo %Baz /; 

our $Foo = "bar"; 

our %Baz = (quux => "potrzebie"); 

1; 

现在全包的名称不再是必要的:

#! /usr/bin/perl 

use warnings; 
use strict; 

use MyConfig; 

print "Foo = $Foo\n"; 

print $Baz{quux}, "\n"; 

你可以添加一个只读标量MyConfig.pm

our $READONLY; 
*READONLY = \42; 

这记录在perlmod

将它添加到@MyConfig::EXPORT后,你可以尝试

$READONLY = 3; 

在不同的模块,但你会得到

Modification of a read-only value attempted at ./program line 12.

作为替代方案,你可以在MyConfig.pm常量使用constant声明然后导出这些模块。

+2

与其从'Exporter'继承,不如从'import'方法,这是你真正需要的。例如'使用Exporter'import';' – friedo 2010-01-21 15:04:10

4

不要使用全局变量进行配置,也不要将配置作为代码使用。关于这一点,我有一整章Mastering Perl

取而代之,创建一个配置类,其他任何包都可以使用该配置类来访问配置数据。从长远来看,为你可能想要改变的事情提供一个界面比通过散布你必须支持你的余生的变量名称来处理你锁定自我的疯狂更容易。

配置接口还可以通过组合实际配置数据的正确位来为配置问题提供新答案。你将所有这些隐藏在一个方法的后面,而更高层次不必看到它是如何实现的。例如,

print "Hello!" unless $config->be_silent; 

be_silent答案可以触发多种原因的更高级别的代码并不需要了解。它可能来自用户开关,程序检测到它不是交互式的,等等。它也可以通过诸如调试开关之类的选项来翻转,该开关覆盖所有其他偏好。不管你做什么决定,代码行都不会改变,因为该陈述只关心答案,而不是你如何得到答案。

相关问题