4

Having read this question and this question on the differences between my $var and my ($var), I was still unable to see why the Data::Dumper module uses parens in the following excerpt from its code. None of the differences described in the answers to those questions seem to apply here.

  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
       };

I tested it out in a small script and I can't perceive any difference between declaring this as my ($s) or as my $s. In both cases it is a scalar reference to a hash, so far as I can tell.

Am I missing something?

temporary_user_name
  • 35,956
  • 47
  • 141
  • 220

2 Answers2

6

I agree, it is weird. In general parentheses on the left side of an assignment force the right side to be evaluated in list context instead of scalar context. But that accomplishes nothing in the above example.

It does, however, seem to be consistent with many other needless uses of my(...) = ... in Data::Dumper, such as this one:

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

Still, it's not consistent, as you also find plenty of examples where it's not used, such as:

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

Maybe it's an occasional personal preference of the author, or else they planned for multiple assignment and never cleaned up their code after... Or maybe multiple authors with different preferences who hesitated to step on each others' toes, or fix what they figured wasn't broke. But that's just speculation...

jrefior
  • 4,092
  • 1
  • 19
  • 29
4

There's no reason for my ($s) to be used here instead of my $s. I can't even fathom a stylistic reason. It is indeed weird.

ikegami
  • 367,544
  • 15
  • 269
  • 518