这种复杂类型问题的第一个借口缺乏最小的非工作示例,但代码确实太复杂而无法导出 MWE。 无论如何,我会尝试解释这个问题:
从一个在 Perl 中使用多个具有多重和重复继承的类的工作系统开始(掌握这导致了代码的复杂性),我想更改由一组具有
Enum
类型的常量实现的“枚举”发明了。
Enum
会像以前一样生成常量,但它也会将名称记住为字符串,因此可以将名称转换为数字,然后再转换回来......
简而言之,
Auth::VerifyStatus.pm
中的代码片段将创建一个枚举(真正的枚举更复杂):
use Enum v1.0.0;
use constant _VERIFY_STATI => Enum->new('VS_STAT', [qw(OK ERR_BAD ERR_INVALID)]);
生成的常量将是基本名称与列表项的串联,例如
VS_STAT_OK
、VS_STAT_ERR_BAD
、...
该包将允许导出常量和枚举,类似于此(消除复杂性):
%EXPORT_TAGS = (
'enums' => [qw(_VERIFY_STATI)],
'status_enum' => [_VERIFY_STATI->names()],
);
names
方法返回由Enum
生成的名称(常量)列表。
现在我有另一个名为
Auth::Verifier.pm
的包,它可以 use Auth::VerifyStatus v1.7.0 qw(:status_enum);
并且(因为这似乎是必要的)也可以重新导出状态常量:
%EXPORT_TAGS = (
'enums' => [qw(Auth::VerifyStatus::_VERIFY_STATI)],
'status_enum' =>
[map { 'Auth::VerifyStatus::' . $_ }
Auth::VerifyStatus::_VERIFY_STATI->names()]);
(我在尝试使其工作时添加了
map
以限定该包,因为我遇到了意想不到的问题)
试图调试情况,但一无所获;我唯一知道的是,运行
1;
时,问题在 Auth::Verifier
中的最后一个 perl -MAuth::Verifier -de1
之后开始:
...
Auth::Verifier ONE
Auth::Verifier::CODE(0x2224de0)(lib/Auth/Verifier.pm:261):
261: 1;
DB<1> c
Constant subroutine Auth::VerifyStatus::VS_STAT_OK redefined at -e line 0.
main::BEGIN() called at -e line 0
eval {...} called at -e line 0
Prototype mismatch: sub Auth::VerifyStatus::VS_STAT_OK () vs none at -e line 0.
main::BEGIN() called at -e line 0
eval {...} called at -e line 0
...
(“ONE”输出被添加到包末尾的
1;
之前,仅用于调试目的)
Exporter
在BEGIN
块中进行评估,这似乎也是必要的,就像这样(也在另一个包中):
our (@EXPORT, @EXPORT_OK, %EXPORT_TAGS, @ISA, $VERSION);
BEGIN {
use Exporter qw(import);
$VERSION = v1.7.0;
$DB::single = 1; # trying to debug this
@ISA = qw(Flags);
%EXPORT_TAGS = (
...
所以我完全不知道如何以合理的方式调试这个(太多“第0行”),或者如何解决这个问题。 或者我对 Perl 的要求太高而应该使用真正的面向对象语言?
被迫自己解决问题,看来这个改变解决了问题:
我没有使用
map { 'Auth::VerifyStatus::' . $_ }
,而是使用了map { '&Auth::VerifyStatus::' . $_ }
(前面添加了&
),并且perl -MAuth::Verifier -de1
毫无问题地继续使用main::(-e:1): 1
。
我仍然必须检查更深的层次结构。