perl – 为什么不从@ARGV / @ _映射读取？

我不能说为什么拉里没有制作地图,grep和其他列表功能在@_像pop和shift一样操作,但我可以告诉你为什么我不会.默认变量过去很流行,但Perl程序员发现大多数“默认”行为导致的问题多于他们解决的问题.我怀疑他们今天会把它变成语言.

第一个问题是记住函数在传递没有参数时的作用.它是否作用于隐藏变量？哪一个？你只需要通过死记硬背,这使得学习,阅读和编??写语言的工作量大大增加.你可能会弄错它,这意味着错误.这可以通过Perl对它的一致性来缓解(即,所有采用列表操作的函数都在@_和所有函数上运行,这些函数使得标量在$_上运行)但是存在更多问题.

第二个问题是基于上下文的行为更改.在子程序之外取一些代码,或将其放入子程序中,突然它的工作方式不同.这使得重构变得更难.如果你只使用@_或只是@ARGV,那么这个问题就会消失.

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

第四,它可能会导致复杂的语法问题.我认为这是保持它不被添加到语言中的原始原因之一,当$_流行时.

第五,当你编写主要使用@ARGV的脚本时,@ ARGV作为默认值是有意义的……但是在处理库时没有任何意义. Perl程序员已经从编写快速脚本转向编写库.

第六,使用$_作为默认值是一种将标量操作链接在一起而不必反复写入变量的方法.如果Perl对其返回值更加一致,并且如果正则表达式没有特殊语法,那么这可能已经减轻了,但是你有它.列表已经可以链接,映射{…} sort {…} grep /…/,@ foo,以便用例由更有效的机制处理.

最后,它的使用非常有限.您想要将@_传递给map和grep是非常罕见的.隐藏默认值的问题远远大于避免键入两个字符.当Perl主要用于快速和肮脏的工作时,这种空间节省可能稍微有点意义,但是在编写超出几页代码的任何内容时没有任何意义.

PS转移默认为@_已经在我的$self = shift中找到了一个利基,但我发现这只是闪耀,因为Perl的参数处理非常糟糕.