| > Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a.
>
> That's not really a style thing, it's a Perl thing, for better or for worse. That code confused me after working in nothing but Perl for 4 years. It was confusing because I wasn't used to people having an array (@_ in this case) and a scalar ($_) named the same thing, and used in close approximation. The issue could have been avoided by (e.g.) setting $_[2] to a variable first, and would have made the code more readable. It's not "Perl 101" to write code that is intentionally obtuse. > Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl. That code could be written in a way that was easier to read and maintain. For example, what is 'shift' intended to be? The only information we have is that it's supposed to be the first argument to function1. Edit: > Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters This was in a code base with a source filter to provide function parameters. That could have been written as: sub function1($arg1, $arg2, $arg3) {
}
in that code base, but the developer in question chose not to.Even without said source filter, you can still name the function parameters: sub function1 {
my ($arg1, $arg2, $arg3) = @_;
}
|
"shift->method()" a very standard Perl idiom for OO code. If you presume the code was called via a blessed reference, then "shift" == "this".