Re^4: split to hash, problem with random keys

Just a question on this, because I can't be bothered to dig it out myself. Will something the following still work as expected?

my %new_hash;

@new_hash{map munge($_), keys %old_hash} = value %old_hash;
[download]

This depends on the sequence of elements returned being identical and is the only way I ever depend on order in a hash.

Makeshifts last the longest.

Comment on Re^4: split to hash, problem with random keys Download Code

Replies are listed 'Best First'.
Re: Re^4: split to hash, problem with random keys by BrowserUk (Patriarch) on Jul 21, 2003 at 22:32 UTC
From perlfunc:keys The actual random order is subject to change in future versions of perl, but it is guaranteed to be the same order as either the values or each function produces (given that the hash has not been modified). As far as I'm aware, the only way to iterate the values of a hash (internally), is to iterate the keys and use them to retrieve the values, so unless an extra step was added to randomise them after retrieval, the returns from keys and values (and each) would have to come back in the same order? Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller	[reply]
Re: Re: Re^4: split to hash, problem with random keys by demerphq (Chancellor) on Jul 22, 2003 at 12:38 UTC
As far as I know this should be fine. The problem will be that the order will/may be different on two seperate program runs, but afaik it should be identical on a single program run (or else as BrowserUk points out values() will have a problem). --- demerphq _{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}	[reply] [d/l]