从Perl5.10开始,现在可以在词法上限定上下文变量$_
的作用域,或者显式地作为my $_;
,或者在given / when
构造中。
有没有人发现词法$_
的好用法?它是否使任何构造更简单/更安全/更快?
如果它使情况变得更加复杂,那该怎么办?词法$_
是否在您的代码中引入了错误?(因为写入$_
的控制结构将使用词法版本,如果它在作用域中,这可能会改变代码的行为,如果它包含任何子例程调用(由于失去动态作用域))
最后,我想构建一个列表,阐明何时将$_
用作词法、全局词或无关紧要的词。
NB: as of perl5-5.24
这些实验特征是no longer part of perl。
发布于 2010-08-05 00:49:13
从词法$_
中脱颖而出的一个伟大的东西是新的_
原型符号。
这允许您指定子例程,以便它将接受一个标量,或者如果没有提供任何标量,它将获取$_
。
因此,与其写:
sub foo {
my $arg = @_ ? shift : $_;
# Do stuff with $_
}
我可以写:
sub foo(_) {
my $arg = shift;
# Do stuff with $_ or first arg.
}
不是很大的改变,但当我想要这种行为时,它就会变得简单得多。删除样板文件是一件好事。
当然,这会产生连锁反应,改变几个内置组件(例如chr
)的原型,这可能会破坏一些代码。
总体而言,我欢迎词法$_
。它给了我一个工具,我可以用它来限制意外的数据转换和函数之间奇怪的交互。如果我决定在函数体中使用$_
,通过对其进行词汇化,我可以确保无论我调用什么代码,$_
在调用代码时都不会被修改。
动态作用域很有趣,但在大多数情况下,我需要词法作用域。此外,围绕$_
的复杂性也增加了。我听到过关于简单地执行local $_;
是不可取的可怕警告--最好改用for ( $foo ) { }
。无论如何,当我本地化$_
时,词典化的$_
会给我99次想要的东西。词法$_
提供了极大的便利性和更健壮的可读性。
我的大部分工作都必须使用Perl5.8,所以我还没有在更大的项目中使用词法$_
的乐趣。然而,感觉这会让$_
的使用变得更安全,这是一件好事。
发布于 2010-08-05 02:44:57
我曾经发现在我使用Inline
模块时出现了一个issue (bug可能是一个过于强烈的词)。这个简单的脚本:
use strict qw(vars subs);
for ('function') {
$_->();
}
sub function {
require Inline;
Inline->bind(C => <<'__CODE__');
void foo()
{
}
__CODE__
}
失败并显示Modification of a read-only value attempted at /usr/lib/perl5/site_perl/5.10/Inline/C.pm line 380.
错误消息。在Inline
模块的内部,有一个想要修改$_
的子例程,这导致了上面的错误消息。
使用
for my $_ ('function') { ...
或者声明my $_
是解决此问题的可行方法。
(对Inline
模块进行了修补,以解决此特定问题)。
发布于 2015-03-09 23:15:23
基本原理: perl这是一个简短的附加答案,其中包含对可能路过的新手的快速总结。当搜索"perl lexical topic“时,可以在这里结束。
到目前为止(2015年),我想大家都知道,词法主题(my $_
和一些相关功能)的引入导致了一些在一开始很难发现的意外行为,marked作为experimental,然后进入了deprecation stage。
#RT119315
的部分总结:一个建议是类似use feature 'lextopic';
to make use of a new lexical topic variable: 的东西。提出的另一个观点是,当"implicit name for the topicalizing operator ... other than$_
“与明确的词法函数(例如,词法map
或lmap
)相结合时,效果最好。目前尚不清楚这些方法是否能以某种方式挽救given/when
。在实验和折旧阶段的来世中,可能会有一些东西最终生活在CPAN的河流中。
https://stackoverflow.com/questions/3400066
复制相似问题