blocks|key|303663|text|这里没有任何问题，尽管当涉及到Perls魔术时，我倾向于遵循某种程度上的“不问不说”的策略。也就是说，例程通常不会依赖于他们的同行来处理非词汇数据作为副作用，也不会让他们这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|303664|我已经针对各种5.8和5.10版本的perl测试了代码，同时偶尔使用5.6描述Camel作为参考。没有任何问题。我的大部分内容最初是为perl+5.8.8完成的。|303665|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Haven't had any problems here, although I tend to follow somewhat of a "Don't ask, don't tell" policy when it comes to Perls magic. I.e. the routines are not usually expected to rely on their peers screwing with non lexical data as a side effect, nor letting them.

I've tested code against various 5.8 and 5.10 versions of perl, while using a 5.6 describing Camel for occasional reference. Haven't had any problems. Most of my stuff was originally done for perl 5.8.8.

blocks|key|3030153|text|从词法$_中脱颖而出的一个伟大的东西是新的_原型符号。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3030154|这允许您指定子例程，以便它将接受一个标量，或者如果没有提供任何标量，它将获取$_。|3030155|因此，与其写：|3030156|sub+foo+{
++++my+$arg+=+@_+?+shift+:+$_;

++++#+Do+stuff+with+$_
}|code-block|syntax|javascript|3030157|我可以写：|3030158|sub+foo(_)+{
++++my+$arg+=+shift;

++++#+Do+stuff+with+$_+or+first+arg.
}|3030159|不是很大的改变，但当我想要这种行为时，它就会变得简单得多。删除样板文件是一件好事。|3030160|当然，这会产生连锁反应，改变几个内置组件(例如chr)的原型，这可能会破坏一些代码。|3030161|总体而言，我欢迎词法$_。它给了我一个工具，我可以用它来限制意外的数据转换和函数之间奇怪的交互。如果我决定在函数体中使用$_，通过对其进行词汇化，我可以确保无论我调用什么代码，$_在调用代码时都不会被修改。|3030162|动态作用域很有趣，但在大多数情况下，我需要词法作用域。此外，围绕$_的复杂性也增加了。我听到过关于简单地执行local+$_;是不可取的可怕警告--最好改用for+(+$foo+)+{+}。无论如何，当我本地化$_时，词典化的$_会给我99次想要的东西。词法$_提供了极大的便利性和更健壮的可读性。|3030163|我的大部分工作都必须使用Perl5.8，所以我还没有在更大的项目中使用词法$_的乐趣。然而，感觉这会让$_的使用变得更安全，这是一件好事。|3030164|entityMap^0|3|2|L|1|0|12|2|0|0|0|0|0|0|N|3|0|A|2|1O|2|2G|2|0|W|2|1I|9|26|G|2X|2|35|2|3L|2|0|11|2|1F|2|0^^$0|@$1|2|3|4|5|6|7|14|8|@$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|19|8|@$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1C|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1D|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|1E|8|@]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1F|8|@]|D|@]|E|$M|N]]|$1|S|3|T|5|6|7|1G|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|1K|8|@$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1R|8|@$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]|$9|20|A|21|B|C]|$9|22|A|23|B|C]]|D|@]|E|$]]|$1|10|3|11|5|6|7|24|8|@$9|25|A|26|B|C]|$9|27|A|28|B|C]]|D|@]|E|$]]|$1|12|3|-4|5|6|7|29|8|@]|D|@]|E|$]]]|13|$]]

IMO, one great thing to come out of lexical <code>$_</code> is the new <code>_</code> prototype symbol.

This allows you to specify a subroutine so that it will take one scalar or if none is provided it will grab <code>$_</code>.

So instead of writing:

<pre><code>sub foo {
 my $arg = @_ ? shift : $_;

 # Do stuff with $_
}
</code></pre>

I can write:

<pre><code>sub foo(_) {
 my $arg = shift;

 # Do stuff with $_ or first arg.
}
</code></pre>

Not a big change, but it's just that much simpler when I want that behavior. Boilerplate removal is a good thing.

Of course, this has the knock on effect of changing the prototypes of several builtins (eg <code>chr</code>), which may break some code.

Overall, I welcome lexical <code>$_</code>. It gives me a tool I can use to limit accidental data munging and bizarre interactions between functions. If I decide to use <code>$_</code> in the body of a function, by lexicalizing it, I can be sure that whatever code I call, <code>$_</code> won't be modified in calling code.

Dynamic scope is interesting, but for the most part I want lexical scoping. Add to this the complications around <code>$_</code>. I've heard dire warnings about the inadvisability of simply doing <code>local $_;</code>--that it is best to use <code>for ( $foo ) { }</code> instead. Lexicalized <code>$_</code> gives me what I want 99 times out of 100 when I have localized <code>$_</code> by whatever means. Lexical <code>$_</code> makes a great convenience and readability feature more robust.

The bulk of my work has had to work with perl 5.8, so I haven't had the joy of playing with lexical <code>$_</code> in larger projects. However, it feels like this will go a long way to make the use of <code>$_</code> safer, which is a good thing.

blocks|key|3030187|text|我曾经发现在我使用Inline模块时出现了一个issue+(bug可能是一个过于强烈的词)。这个简单的脚本：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3030188|use+strict+qw(vars+subs);
for+('function')+{
++++$_->();
}
sub+function+{
++require+Inline;
++Inline->bind(C+=>+<<'__CODE__');
void+foo()+
{
}
__CODE__
}|code-block|syntax|javascript|3030189|失败并显示Modification+of+a+read-only+value+attempted+at+/usr/lib/perl5/site_perl/5.10/Inline/C.pm+line+380.错误消息。在Inline模块的内部，有一个想要修改$_的子例程，这导致了上面的错误消息。|3030190|使用|3030191|for+my+$_+('function')+{+...|3030192|或者声明my+$_是解决此问题的可行方法。|3030193|(对Inline模块进行了修补，以解决此特定问题)。|3030194|entityMap|0|LINK|mutability|MUTABLE|url|http://search.cpan.org/perldoc?Inline|1|https://rt.cpan.org/Public/Bug/Display.html?id=55607^0|9|6|9|6|0|N|5|1|0|0|5|2Q|31|6|3K|2|0|0|0|4|5|0|2|6|0^^$0|@$1|2|3|4|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@$9|17|A|18|1|19]|$9|1A|A|1B|1|1C]]|E|$]]|$1|F|3|G|5|H|7|1D|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1E|8|@$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|1L|8|@]|D|@]|E|$]]|$1|O|3|P|5|H|7|1M|8|@]|D|@]|E|$I|J]]|$1|Q|3|R|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]]|V|$W|$5|X|Y|Z|E|$10|11]]|12|$5|X|Y|Z|E|$10|13]]]]

I once found an <a href="https://rt.cpan.org/Public/Bug/Display.html?id=55607" rel="nofollow noreferrer">issue</a> (bug would be way too strong of a word) that came up when I was playing around with the <a href="http://search.cpan.org/perldoc?Inline" rel="nofollow noreferrer"><code>Inline</code></a> module. This simple script:

<pre><code>use strict qw(vars subs);
for ('function') {
 $_-&gt;();
}
sub function {
 require Inline;
 Inline-&gt;bind(C =&gt; &lt;&lt;'__CODE__');
void foo() 
{
}
__CODE__
}
</code></pre>

fails with a <code>Modification of a read-only value attempted at /usr/lib/perl5/site_perl/5.10/Inline/C.pm line 380.</code> error message. Deep in the internals of the <code>Inline</code> module is a subroutine that wanted to modify <code>$_</code>, leading to the error message above. 

Using 

<pre><code>for my $_ ('function') { ...
</code></pre>

or otherwise declaring <code>my $_</code> is a viable workaround to this issue.

(The <code>Inline</code> module was patched to fix this particular issue).

blocks|key|3244377|text|基本原理:+perl这是一个简短的附加答案，其中包含对可能路过的新手的快速总结。当搜索"perl+lexical+topic“时，可以在这里结束。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3244378|到目前为止(2015年)，我想大家都知道，词法主题(my+$_和一些相关功能)的引入导致了一些在一开始很难发现的意外行为，marked作为experimental，然后进入了deprecation+stage。|CODE|3244379|3244380|3244381|+#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的河流中。|blockquote|3244382|3244383|entityMap|0|LINK|mutability|MUTABLE|url|http://rjbs.manxome.org/rubric/entry/2018|1|https://metacpan.org/pod/experimental|2|https://rt.perl.org/Public/Bug/Display.html?id=119315|3|4|https://rt.perl.org/Public/Bug/Display.html?id=119315#txn-1246377|5|https://rt.perl.org/Public/Bug/Display.html?id=119315#txn-1244727^0|0|W|0|Q|5|1P|6|0|1X|C|1|2F|H|2|0|0|0|1|9|N|N|4R|2|58|3|5C|4|6B|A|1|9|3|1B|1D|4|34|1P|5|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|18|8|@$9|19|A|1A|B|H]]|D|@$9|1B|A|1C|1|1D]|$9|1E|A|1F|1|1G]|$9|1H|A|1I|1|1J]]|E|$]]|$1|I|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|1M|8|@$9|1N|A|1O|B|H]|$9|1P|A|1Q|B|H]|$9|1R|A|1S|B|H]|$9|1T|A|1U|B|H]|$9|1V|A|1W|B|H]|$9|1X|A|1Y|B|H]]|D|@$9|1Z|A|20|1|21]|$9|22|A|23|1|24]|$9|25|A|26|1|27]]|E|$]]|$1|N|3|-4|5|6|7|28|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|29|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]|W|$5|R|S|T|E|$U|X]]|Y|$5|R|S|T|E|$U|Z]]|10|$5|R|S|T|E|$U|Z]]|11|$5|R|S|T|E|$U|12]]|13|$5|R|S|T|E|$U|14]]]]

[ Rationale: A short additional answer with a quick summary for perl newcomers that may be passing by. When searching for "perl lexical topic" one can end up here.]

By now (2015) I suppose it is common knowledge that the introduction of lexical topic (<code>my $_</code> and some related features) led to some difficult to detect at the outset unintended behaviors and so was <a href="http://rjbs.manxome.org/rubric/entry/2018" rel="nofollow">marked</a> as <a href="https://metacpan.org/pod/experimental" rel="nofollow">experimental</a> and then entered into a <a href="https://rt.perl.org/Public/Bug/Display.html?id=119315" rel="nofollow">deprecation stage</a>.

<hr>

<blockquote>
 Partial summary of <a href="https://rt.perl.org/Public/Bug/Display.html?id=119315" rel="nofollow"><code>#RT119315</code></a>:
 One suggestion was for something like <code>use feature 'lextopic';</code> <a href="https://rt.perl.org/Public/Bug/Display.html?id=119315#txn-1246377" rel="nofollow">to make use of a new
 lexical topic variable:
 <code>$^_</code></a>.
 Another point made was that an "<a href="https://rt.perl.org/Public/Bug/Display.html?id=119315#txn-1244727" rel="nofollow">implicit name for the topicalizing operator ... other than <code>$_</code></a>" would work best when combined with explicitly lexical functions (e.g. lexical <code>map</code> or <code>lmap</code>). Whether these approaches would somehow make it possible to salvage <code>given/when</code> is not clear. In the afterlife of the experimental and depreciation phases perhaps something may end up living on in the river of CPAN.
 
</blockquote>

Starting in Perl 5.10, it is now possible to lexically scope the context variable <code>$_</code>, either explicitly as <code>my $_;</code> or in a <code>given / when</code> construct.

Has anyone found good uses of the lexical <code>$_</code>? Does it make any constructs simpler / safer / faster?

What about situations that it makes more complicated? Has the lexical <code>$_</code> introduced any bugs into your code? (since control structures that write to <code>$_</code> will use the lexical version if it is in scope, this can change the behavior of the code if it contains any subroutine calls (due to loss of dynamic scope))

In the end, I'd like to construct a list that clarifies when to use <code>$_</code> as a lexical, as a global, or when it doesn't matter at all.

<hr>

NB: as of <code>perl5-5.24</code> these experimental features are <a href="http://www.effectiveperlprogramming.com/2016/04/lexical-_-and-autoderef-are-gone-in-v5-24/" rel="nofollow noreferrer">no longer part of perl</a>.

The good, the bad, and the ugly of lexical $_ in Perl 5.10+

数据转换

从Perl5.10开始，现在可以在词法上限定上下文变量$_的作用域，或者显式地作为my $_;，或者在given / when构造中。有没有人发现词法$_的好用法？它是否使任何构造更简单/更安全/更快？如果它使情况变得更加复杂，那该怎么办？词法$_是否在您的代码中引入了错误？(因为写入$_的控制结构将使用词法版本，如果...

问Perl 5.10+中词法$_的优点、缺点和丑陋
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Perl 5.10+中词法$_的优点、缺点和丑陋EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Perl 5.10+中词法$_的优点、缺点和丑陋
EN