in reply to Bulk Hash Assignment

in the beginning, there was foo...

#!/usr/bin/perl -w
use strict;

my %foo = (
    camshaft   => 'lumpy',
    gearbox    => 'shifty',
    drivetrain => 'speedy',
    smokestack => 'dirty',
    lights     => 'bright eyes',
);

[download]
but foo was alone. so bar was created.

my %bar;
@bar{ qw/camshaft gearbox1 the_drivetrain _other/ } = '';

[download]
but bar was different... and empty. foo wants to understand bar, and a map was made...

my %map_foo_to_bar = (
    camshaft   => 'camshaft',
    gearbox    => 'gearbox1',
    drivetrain => 'the_drivetrain',
    smokestack => 'my_smokestack',
    junkyard   => '_junkyard',
);

[download]
still, bar was empty, so along comes schlep to help...

sub schlep($$$)
{
    my( $map_ref, $from_ref, $to_ref ) = ( shift, shift, shift );
    for( keys %{ $from_ref } )
    {
        $to_ref->{ $map_ref->{$_} } = $from_ref->{$_}
            if( exists $map_ref->{$_} && exists $to_ref->{ $map_ref->{
+$_} } )
    }
}

schlep(\%map_foo_to_bar, \%foo, \%bar);

use Data::Dumper;
print Dumper \%bar;

[download]
so it is written, so it shall be done.

~Particle ;Þ

Replies are listed 'Best First'.
Re^2: Bulk Hash Assignment
by tadman (Prior) on Apr 17, 2002 at 20:40 UTC
    That's surprisingly complicated for what I thought was a simple task: 
    sub schlep
{
        my ($p,$q,%p2q) = @_;

        @{$q}{values %p2q} = @{$p}{keys %p2q};
}

    [download]
    Of course, this does assume that values and keys will always output in precisely the same order. Not that I have been given any reason to believe that they would do something to the contrary.
[reply]
[d/l]
      well, this looks simple. i haven't run it, but it looks like it will work if %$p and %$q implement exactly the same keys. my example works on the intersection of keys between %foo and %bar (only the keys both hashes share.) perhaps i solved a more general problem than the original poster requested.

      question: what happens to your code if a key exists in %p2q, but not in %$p? my code will not auto-vivify a key in %$q. will yours?

      by the way, values and keys are guaranteed to output in the same order (in the same hash.) this is by no means guaranteed in different hashes. see each for a little detail.

      ~Particle ;Þ

[reply]
        Well, the idea was that you would only ask to export that particular key if it was defined in p in the first place. Further to that, since you are exporting from p to q, if something is not in q, then it should be created. After all, the idea is to move data from p to q. If q was an empty hash, clearly nothing would ever be inserted into it.

        Also, as best as I can tell, reading from a hash at the root level does not create keys, even when using hash slices.

        The idea for schlep() is to move data simply and efficiently from one or more hashes into a single hash, remapping as required since the two namespaces likely differ to some degree.
[reply]
[d/l]
      That's guaranteed. In the very docs you point to.

      I'm not snide, I'm just bitter that you posted the answer before I did.

[reply]

In Section Meditations