print @array; # gives the same result as: print qq{$hash{$_}} for sort keys %hash; # this
No it doesn't. You are printing an array, and printing a hash by first sorting it's keys. They would not give the same result *except* for the case where the array is in the order you want (I hope if you read in a file, noone moved around elements!). So, they are the same, depending on how each was initialized.. but I may be nit picking :)
The matter of the zero-based array is handled by tossing in an unshift(@array,'');, following the read
Why would I want to do that? Now if I somewhere shift, pop, or otherwise alter the array (not the data set itself), things can still get out of whack.
using '05' as a hash key isn't going to help future maintainability).
No? If my file is a large data set (flat file db, maybe) then I think using '5' (remember, if you read my first post, the 0 padding was for nicer printing only) is very maintainable. Well, I don't see how it wouldn't be.. or how using an array would be any more maintainable.
I am not disputing that an array is easy to work with (I like hashes better), isn't quick (hash lookups aren't too slow), or easy to read (well, sometimes they aren't intuitive).. but the original snippet was, again, AWTDI. Maybe at some point we can actually benchmark it with a large file. But, personally, I still like hashes in general for readability, maintainability, form, and function.
Cheers,
K "gobble gobble" M
In reply to Re: Re: Reading file into a numbered hash
by KM
in thread Reading file into a numbered hash
by KM
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |