_____________________________________________________
Jeff japhy Pinyan,
P.L., P.M., P.O.D, X.S.:
Perl,
regex,
and perlhackerHow can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

The problem is that Perl doesn't abstract the concept of appending for its various containers (scalars, arrays, and hashes), because Perl isn't inherently OO. I don't know if Perl 6 is going this route, where you could say:

I'd expect friction coming from the "what does append/prepend mean for hashes?" faction, but I'd say it's a matter of precedence. Appending to a hash, when there are duplicate keys, uses the new values, and prepending would use the old values.

_____________________________________________________
Jeff japhy Pinyan,
P.L., P.M., P.O.D, X.S.:
Perl,
regex,
and perlhackerHow can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

That is easier to read, and much more clearly signals intent. It is also at least as fast as the map version. (It used to be a lot faster, but in Perl 5.8 there is an optimization that causes map to shortcircuit to become a for if it is in null context.)

Furthermore performance is far less likely to matter than most people think, and when it does having micro-optimized as you went is generally a bad strategy for getting it. (You want to keep code clean and then look for a better algorithm, or move a small section into C.) Therefore I would generally use the following strategy because it is even clearer, even though it is marginally slower on my machine (about 10% so):