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

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'
        ];

[download]

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.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^4: hash slice ? No thanks, I'm about to return...
by leriksen (Curate) on Feb 20, 2005 at 23:18 UTC
    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.

    ...it is better to be approximately right than precisely wrong. - Warren Buffet

[reply]

      The value of a line such as: 

        $x = 1;

      [download]
      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;

      [download]
      This too is 1. Not @x.

      Hope this helps.

[reply]
[d/l]
[select]

      What does this print?

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

      [download]

      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;

      [download]

      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'
        ];

      [download]

      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.

      Makeshifts last the longest.

[reply]
[d/l]
[select]
        Firstly, thanx Tanktalus and Aristotle for your patience in trying to get me to understand.

        I think its starting to become clear. The key phrase, as from your first reply post to this, Aristole, is the list of lvalues assigned to. I dont think I really understand what that actually means - so I'll try to explain what I think it means.

        Originally I thought it mean the list of keys and values, but now I see it means just the values part, not the keys. In fact assigning to a key doesnt seem to make much sense - in a hash, a key has a related value, and you can assign to that value, but you can't assign to a key. Except maybe initially, which has the effect of creating the key. I dunno, maybe my language is too loose.

        The values being assigned to are the values of the keys, thats all.

        That said, Aristotle, I really dont understand what your trying to show me with your examples

        Why would an assignment behave differently - I understand that the values returned by the hash slice are joined, but I dont understand how the join and the assignment to a slice are related.

        The aliasing behaviour isn't noise, it is exactly the point. I completely dont understand what your trying to show me ?

        Sorry if I'm being thick, I think I'm getting closer if that helps.

        ...it is better to be approximately right than precisely wrong. - Warren Buffet

[reply]

In Section Meditations