Question

从Perl 5.10开始,现在可以灵活地将背景变量_$_明确作为my_;或given / 构建。

是否有任何人发现对“条码”的使用良好? 它是否使任何建筑更加简单/更安全/更快?

它使局势更加复杂,是什么情况? 是否在法典中引入任何建议? (因为写到<代码>__$_的管制结构如果范围广泛,将使用弹性文本,如果守则包含任何次要呼吁(由于动态范围的损失),则可以改变其行为)

最后,我要提出一个清单,阐明何时将$_用作一种灵活做法,作为全球手段,或当它只处理某一事项时。

<>0>NB:,perl5-5.24 这些实验性特征是:,不再属于每。

Answer 1

海事组织,从lexical 到_上得出的一件大事是新的_原型。

这使你能够具体指明一条小路线,这样它就能够使用一个小数,或者如果没有这样的标记,那么它就能够打碎<>_>$。

因此,不是书面:

sub foo {
    my $arg = @_ ? shift : $_;

    # Do stuff with $_
}

我可以写:

sub foo(_) {
    my $arg = shift;

    # Do stuff with $_ or first arg.
}

这不是一个大的变化,而是在我想要这种行为时更简单。拆船清除是一件好事。

当然,这具有改变一些内装物原型(例如<代码>chr)的效果的炉.,可能会打破一些代码。

总的说来,我欢迎<代码>_。它给我提供了一种工具,我可以用来限制意外数据零散和职能间的互动。如果我决定使用<代码>_$_,通过使其具有灵活性,我可以确信,无论我称之为哪一种代码,_$_在打字时都得改。

动态范围是令人感兴趣的,但大多数情况下,我想进行法性的范围。在<代码>后添加“。我听到了可怕的警告,即干 doing的不可取性: local$_;--最好使用for( foo ){。缩略语<代码>__$_,在我以任何手段将<代码>上填满100时,我需要99倍。缩略语:$_使“方便”和“可读性”特征更为有力。

我的大部分工作不得不按每秒5.8开展工作,因此,我有幸在大型项目中以灵活方式玩弄$_。然而,它感到,这样做将大大有助于使“<<> >>$_更安全,这是一件好事。

Answer 2

我曾找到了。当我与 <>>:Inline模块一起玩.时,这段话的字体会过于强烈。这一简明文字:

use strict qw(vars subs);
for ( function ) {
    $_->();
}
sub function {
  require Inline;
  Inline->bind(C => << __CODE__ );
void foo() 
{
}
__CODE__
}

见Modification of a Read-only Valuequest at /usr/lib/perl5/site_perl/5.10/Inline/C.pm line 380. 深植于<代码>Inline模块内部,是一种替代方式,希望修改$_,从而形成上述错误信息。

使用

for my $_ ( function ) { ...

或宣布<代码>my_是解决这一问题的可行工作。

(Inline的模块被配上,以固定这一具体问题。)

Answer 3

[Rationale: 附加一个简短的答案,即对可能通过的新商迅速作出总结。在寻找“常规”专题时,可以在此结束。]

到现在(2015年) 众所周知,引入弹性专题(my 和一些相关特征)使得在最初出现意外行为时难以发现某些行为,因此,>marked ,然后进入

Partial summary of #RT119315: One suggestion was for something like use feature lextopic ; to make use of a new lexical topic variable: $^_. Another point made was that an "implicit name for the topicalizing operator ... other than $_" would work best when combined with explicitly lexical functions (e.g. lexical map or lmap). Whether these approaches would somehow make it possible to salvage given/when is not clear. In the afterlife of the experimental and depreciation phases perhaps something may end up living on in the river of CPAN.

Answer 4

这里没有任何问题,尽管我倾向于采取某种“ ask问”政策,在涉及Perls魔鬼时,不要说 t。 I.e. 例行公事不会通常,期望依靠同龄人用非硬性数据作副作用,也不会让他们 let。

我用5.6个版本描述Camel偶尔参考,对照5.8和5.10版本进行了测试。 Have没有问题。我的 st子大部分是原为5.8 per。

友情链接