in reply to Re: Bulk Hash Assignment
in thread Bulk Hash Assignment

That's surprisingly complicated for what I thought was a simple task:
sub schlep { my ($p,$q,%p2q) = @_; @{$q}{values %p2q} = @{$p}{keys %p2q}; }
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.

Replies are listed 'Best First'.
Re: Re^2: Bulk Hash Assignment
by particle (Vicar) on Apr 17, 2002 at 21:12 UTC
    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 ;Þ

      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.
Re: Re^2: Bulk Hash Assignment
by pdcawley (Hermit) on Apr 19, 2002 at 07:31 UTC
    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.