Re^2: hash slice ? No thanks, I'm about to return...

[leriksen]

My intent was to return a list of key-value pairs, as in the code sample - and I'm not sure I agree with your doc-quote

… a list assignment in list context produces the list of lvalues assigned to, …

Isnt the list assigned to the hash(or list of key/value pairs) %return ?
Isnt the list assigned to on the left hand side of the '=' ?
In the second code samples case that would be (a,1,b,2,c,3,d,4), yes?

The list assigned _from_ is what I'm seeing returned..

Apart from that the list-fu is a neat trick, but perhaps the explicit return is more appropriate, as discussed later in this thread, or a better understanding of when to use return...

[Aristotle]

You misunderstand.

No, the list assigned to is not %return. You are taking a hash slice. The hash as a whole is nowhere to be seen in this assignment. I get the feeling that you haven't understood exactly what taking a slice does.

Yes, the list assigned to is on the left hand of the assignment operator.

I'm not sure which second code sample you are talking about.

You are not seeing the list assigned from. You are seeing what the list you assigned to evaluates to, which in this case is 1, 2, 3, 4. The distinction is subtle and may be confusing but you are indeed getting the list assigned to:

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;

my %return;
my @value = qw( foo bar baz quux );

$_ = uc $_
    for @return{ qw( a b c d ) } = @value;

print Dumper( \%return ), Dumper( \@value );

=begin output
$VAR1 = {
          'c' => 'BAZ',
          'a' => 'FOO',
          'b' => 'BAR',
          'd' => 'QUUX'
        };
$VAR1 = [
          'foo',
          'bar',
          'baz',
          'quux'
        ];

As you can see, the $_ = uc $_ assignment changed the values in the hash. If you were getting the list assigned from, it would have changed the values in @value.

[leriksen]

I had considered trying to take this off-line, but if I am still confused, maybe others are.

My question is, why does the list assigned to not include the keys as well ?

And perhaps can you give an example that doesn't use $_ with all its aliasing behaviour just adding to the noise.

[Tanktalus]

The value of a line such as:

  $x = 1;

is 1. Obviously. But the reason it's one is not because $x is now set to 1. It's because the RHS is 1. Thus, if I do this:

  $x[0] = 1;

This too is 1. Not @x.

Hope this helps.

[Aristotle]

What does this print?

print join ' ', @return{ @keys };

Why would an assignment behave differently? And if it should include the keys, then what should happen if you said this?

( $foo, $bar, @return{ @keys } ) = 1 .. 10;

And perhaps can you give an example that doesn't use $_ with all its aliasing behaviour just adding to the noise.

The aliasing behaviour isn't noise, it is exactly the point. The aliasing behaviour makes a difference because the assignment returns the list of lvalues that were assigned to. If the assignment returned copies, then nothing in the original array would change. Let's do that again, but making sure to pass copies this time:

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;

my %return;
my @value = qw( foo bar baz quux );

$_ = uc $_
    for @{ [ @return{ qw( a b c d ) } = @value ] };

print Dumper( \%return ), Dumper( \@value );

=begin output
$VAR1 = {
          'c' => 'baz',
          'a' => 'foo',
          'b' => 'bar',
          'd' => 'quux'
        };
$VAR1 = [
          'foo',
          'bar',
          'baz',
          'quux'
        ];

This time, the changes are lost in the mist of time, because we didn't operate on the list of lvalues assigned to, we operated on copies of their values.