为什么 Dumper 模块在其设置哈希的分配周围放置括号？答案

【问题标题】：Why does the Dumper module place parens around the assignment of its settings hash?为什么 Dumper 模块在其设置哈希的分配周围放置括号？
【发布时间】：2017-05-24 21:56:23
【问题描述】：

阅读了this question 和this question 关于my $var 和my ($var) 之间差异的内容后，我仍然无法理解为什么Data::Dumper 模块在其代码的以下摘录中使用括号。这些问题的答案中描述的差异似乎都不适用于这里。

  my($s) = {
        level      => 0,           # current recursive depth
        indent     => $Indent,     # various styles of indenting
        # a bunch of other settings removed for brevity's sake
        deparse    => $Deparse,    # use B::Deparse for coderefs
        noseen     => $Sparseseen, # do not populate the seen hash unless necessary
       };

我在一个小脚本中对其进行了测试，我看不出将其声明为 my ($s) 或 my $s 之间有什么区别。据我所知，在这两种情况下，它都是对哈希的标量引用。

我错过了什么吗？

【问题讨论】：

标签： perl

【解决方案1】：

我同意，这很奇怪。一般来说，赋值左侧的括号强制右侧在列表上下文而不是标量上下文中进行评估。但这在上面的例子中没有任何作用。

然而，它似乎与 Data::Dumper 中 my(...) = ... 的许多其他不必要的用法一致，例如这个：

sub Reset {
  my($s) = shift;
  $s->{seen} = {};
  return $s;
}

不过，它并不一致，因为您还会发现很多未使用它的示例，例如：

my $ref = \$_[1];
my $v;

也许这是作者偶尔的个人偏好，或者他们计划进行多次分配并且在之后从未清理过他们的代码......或者可能是多个具有不同偏好的作者，他们犹豫着踩到彼此的脚趾，或者修复什么他们认为没有破产。但这只是猜测......

【讨论】：

【解决方案2】：

这里没有理由使用my ($s) 代替my $s。我什至无法理解风格上的原因。确实很奇怪。

【讨论】：