使用 nextsame 或 callame 时奇怪的“不能使用未知特征”
Posted
技术标签:
【中文标题】使用 nextsame 或 callame 时奇怪的“不能使用未知特征”【英文标题】:Weird "Can't use unknown trait" when nextsame or callsame are used 【发布时间】:2021-10-01 16:32:23 【问题描述】:这是程序:
my %SUB-COUNTS;
say "Start";
multi sub trait_mod:<is>(Sub $s where .name().contains("-logged"), :$AOP)
$s.wrap(
say "Entering $s.name ";
callsame;
);
multi sub trait_mod:<is>(Sub $s where .name().contains("-counted"), :$AOP)
$s.wrap(
say "Counting $s.name ";
%SUB-COUNTS$s.name++;
);
sub water-logged() is AOP
return "Water";
sub out-logged() is AOP
return "Out";
sub we're-counted() is AOP
state $count = 0;
return $count++;
sub we're-counted-and-logged() is AOP
state $alpha = 'a';
return $alpha++;
say water-logged(), " ", out-logged(), " ", water-logged();
say we're-counted() for ^20;
say we're-counted-and-logged() for ^20;
say %SUB-COUNTS;
这可行,但每个例程只能应用 1 个特征,所以我考虑使用重新调度,以便可以计算和记录例程。但是,这样做:
multi sub trait_mod:<is>(Sub $s where .name().contains("-logged"), :$AOP)
$s.wrap(
say "Entering $s.name ";
callsame;
);
callsame;
导致奇怪的编译错误:
Can't use unknown trait 'is' -> 'AOP' in a sub declaration.
at /home/jmerelo/txt/docencia/presentaciones/aop-raku/code/point-cut.raku:23
expecting any of:
rw raw hidden-from-backtrace hidden-from-USAGE pure default
implementation-detail DEPRECATED inlinable nodal prec equiv
tighter looser assoc leading_docs trailing_docs
第 23 行是第一个使用 AOP
的声明。所以我有点迷失在这里。为什么添加单个语句会以这种方式改变语法?
【问题讨论】:
【参考方案1】:不幸的是,如果没有找到匹配的特征,trait_mod:<is>
有一个 multi
候选 reports an error。可以说,与针对 trait 修饰符的标准多重分派错误相比,当一个错误类型的特征名称时,这会提供更好的错误消息。然而,就多重调度而言,它和其他任何一个候选者一样,callsame
会正确地服从它。
虽然值得要求以一种没有这种副作用的方式完成更好的错误报告,但我能想到的唯一解决方案是在 callsame
周围使用 try
并抑制未知特征异常.
【讨论】:
但是在这种情况下,会有一个候选人,另一个多,对吧?为什么那个候选人被立即召集?有没有办法改变优先级以便调用正确的优先级? 它转到下一个适用的候选人;counted
仅适用于 sub
的名称同时包含 logged
和 counted
的情况。您的示例中的第一个 sub
是 sub water-logged() is AOP
,因此 counted
不适用,因此下一个最适用的候选者是错误报告者。以上是关于使用 nextsame 或 callame 时奇怪的“不能使用未知特征”的主要内容,如果未能解决你的问题,请参考以下文章
如何使游戏对象列表消失动画? (或如何在设置 alpha 值时解决奇怪的行为)
在 promise.then 或 promise.catch 中调用时,Array.push 的工作很奇怪
应用程序再次激活时 CLLocationManager 的奇怪行为