perl - 为什么不从@ARGV/@_ 读取 map ？

Question

map 有什么好的理由吗？不阅读 @_ (在函数中)或 @ARGV (其他任何地方)当没有给出参数列表时？

Answer 1

我不知道为什么拉里没有制作 map , grep其他列表函数在 @_ 上运行喜欢 pop和 shift做，但我可以告诉你为什么我不会。默认变量曾经很流行，但 Perl 程序员发现大多数“默认”行为导致的问题比他们解决的问题多。我怀疑他们今天会不会把它变成语言。

第一个问题是记住一个函数在不传递参数时做了什么。它是否作用于隐藏变量？哪一个？你只需要死记硬背，这使得学习、阅读和编写语言需要做更多的工作。你可能会弄错，这意味着错误。这可以通过 Perl 对此保持一致来缓解(即，所有采用列表的函数对 @_ 进行操作，所有采用标量的函数对 $_ 进行操作)，但还有更多问题。

第二个问题是基于上下文的行为变化。在子程序之外取一些代码，或者把它放到子程序中，突然它的工作方式就不一样了。这使得重构更加困难。如果你让它在 @_ 上工作或只是 @ARGV那么这个问题就消失了。

第三是默认变量有被悄悄修改和读取的趋势。 $_由于这个原因是危险的，你永远不知道什么时候会覆盖它。如果使用@_由于采用了默认列表变量，因此这种行为可能会泄漏。

第四，它可能会导致复杂的语法问题。我想这是阻止它被添加到语言中的最初原因之一，回到 $_当时很流行。

五、@ARGV当您编写主要用于 @ARGV 的脚本时，默认设置是有意义的。 ...但在图书馆工作时没有任何意义。 Perl 程序员已经从编写快速脚本转向编写库。

六、使用$_默认情况下是一种将标量操作链接在一起的方式，而无需一遍又一遍地写入变量。如果 Perl 的返回值更加一致，并且正则表达式没有特殊语法，那么这可能会得到缓解，但您已经拥有了。列表已经可以链接了，map { ... } sort { ... } grep /.../, @foo ，以便用例由更有效的机制处理。

最后，它的用途非常有限。想通过的人很少见@_至 map和 grep .隐藏默认值的问题远远大于避免输入两个字符。当 Perl 主要用于快速和肮脏的工作时，这种空间节省可能更有意义，但在编写超出几页代码的任何内容时就没有意义了。

PS shift默认为 @_在 my $self = shift 中找到了一个利基市场，但我发现这只是因为 Perl 的参数处理太差了。