Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

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

by leriksen (Curate)
on Feb 20, 2005 at 00:35 UTC ( #432803=note: print w/ replies, xml ) Need Help??


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

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...

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


Comment on Re^2: hash slice ? No thanks, I'm about to return...
Download Code
Re^3: hash slice ? No thanks, I'm about to return...
by Aristotle (Chancellor) on Feb 20, 2005 at 17:45 UTC

    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.

    Makeshifts last the longest.

      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

        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.

        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.

        Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://432803]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (11)
As of 2014-11-28 13:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (197 votes), past polls