Your "shift" is being mistaken for a bareword hash key symbolic reference (thanks, davido for the correction). If you say,

    my %x = %{+shift};
# or
    my %x = %{shift()};
[download]

scalar is working for you, not because of its primary effect of forcing scalar context, but because of one of its secondary effects; of making your expression look like an expression, rather than just a bareword.

For example, you could also have said "my %x = %{+shift}". And that too would have worked.

The point is that %{shift} looks like a hash named "shift". %{+shift} looks like a dereferencing of the return value of the function named shift. And %{scalar shift} is recognized also by the compiler to be a set of function calls instead of just a literal variable name.

davido, I'm surprised and ashamed for you. You should have told him about shift() before or instead of +shift. The former looks normal and has identical functionality while the latter is just an abuse of unary +.

... = %{shift()}

:) Surprise and shame huh?

Is it abuse, or acceptible use? Either way, the Perl world will survive my sin. ;) It's not all that unusual of a sight anyway, though to your point it is not as explicit as shift().

Thanks for the gentle reminder that we shouldn't get too fancy.




Dave

Am I correct that by saying something like

sub mysub {
  my %x = %{+shift};
}
[download]

I'll actually be copying all of the hash entries into a local variable... So if the hash passed into the subroutine is very large, it could be a performance hit? The paradigm I usually use is to shift into a scalar and then use dereference operator to access elements. This may be why... unless you have really good reasons to do it, should one stay away from the paradigm in the code segment above???

First thing's first; diotalevi is right, my %x = %{shift()}; is by far the preferred method. I pulled out the unary + as a prefix that served a similar purpose to your use of scalar in this situation. But it's ultimately a bad example, and shift() is the proper way to do things. Treat a function like a function, (ie, use parens) rather than using the unary plus +.

Now to answer your question: Yes, my %x = %{shift()}; makes a copy of the contents of the hash to a lexical variable. This does cost performance and memory. But there are times when you need a copy, and other times where it's fine to just work with the reference to the original hash, held in $_[0].




Dave

use strict;
use warnings;

my %foo = ( a => 1, b => 2, c => 3 );

mysub(\%foo);

sub mysub {
  our (%x);
  local *x = shift;

  foreach ( sort keys %x ) {
    print "$_ -> $x{$_}\n";
  }
}
[download]

This entire thread never even mentioned @_ once! It mentioned $_[0] exactly once but never used it in code.

So I'll be the first to mention:

    my %h= %{ shift @_ };
[download]

Leaving the target of operations implied is fine for quick hacks, one-liners, and golf. But I usually stress writing code that is easy to maintain so I usually avoid such implied targets. And this means I don't get bit by shift or pop being treated as a string.

It also means that you can easily find where I deal with function arguments. As opposed to this code from a core module. Quick, what arguments does it take?

At least the suggested %{shift()} makes the code somewhat clearer. But both %{+shift} and %{(shift)} are, if anything, somewhat obfuscatory, which isn't an awful thing, but since there are such clearer alternatives I don't consider them good options.

use strict;
use warnings;

my %hash = (1,'a',2,'b',3,'c');
print $hash{2};
mysub(\%hash);
print $hash{2};

sub mysub {
    my $p = shift;
    print $p->{2};
    $p->{2} = 'd';
}
[download]

use strict;
use warnings;

my %hash = (1,'a',2,'b',3,'c');
mysub(\%hash);

sub mysub {
    my %h = %{shift()};
    print $h{2};
}
[download]