map { chomp; $_ => undef} but you should have written map { local $_ = $_; chomp; $_ => undef }.

Abigail

Oh yes, I've read that discussion before in other contexts. My objection was that Limbic~Region was modifying the input as an unintentional side effect. I liken it to avoiding globals and other action-at-a-distance operations. My thinking is that there is a target for the modifications to show up at and that having them show up at both the input and the ouput is unusual at best.

Did you ever watch Ice skating or some similar sport where the scores are determined by a set of judges award marks on the basis of "style"?

Did you ever watch an individual or couple perform a breath-taking, flamboyant, mesmerising & inspirational performance be beaten out by another that gave a technically perfect, totally synchronised, metronomic but ultimately uninspired and frankly boring performance.

If you have, then perhaps you also wished that it was possibly award the judge(s), that ignored or even marked down the first performance, a quick 'nool pwai' and prevent them inflicting further damage :)

Huh? The original code was a jot more complex than it needed to be and you think I'm nitpicking? The operation is in effect targetting both the input data and the output. I don't think that's unreasonable anyway, to expect the programmer to either modify the input or return the modification but not both simultaneously.

Sorry diotalevi, but I guess this is (another) one of those things that we will have to agree to disagree about:)

My comment was based upon your use of the word "style". It was intended to be a vaguely humourous way of indicating that style is in the eye of the beholder and critiquing on the basis of style is a little like saying that you don't like someone else choice of colour. You may not like the colour they favour, but saying that their chioce is wrong makes no sense.

It's equivalent to saying that someones opinion is wrong. You may disagree with their opinion. You may be able to to prove that the facts their opinion is based upon are incorrect. But you cannot say that their opinion is wrong, because it is their opinion, and they alone are the final arbitars.

The point you made about modifying the input list as a side-effect of a map statement has merit. In general, side-effects can be misleading and dangerous. However, in the specific case, as the input list was direct input from a file, and was summarily discarded after use within the map, the effect of the side-effect was also discarded and, as such, will never be available to the rest of the program or anywhere outside of the map. It is therefore impossible that it would ever have a detrimental "confusion factor" on the rest of the code.

The alternative would be to read the file into an array and pass the array to chomp and then supply the chomped array to the map in order to construct the hash. Then discard the chomped array.

All of which would buy you absolutely nothing, as the array would still have been modified as a side-effect of passing into chomp. All that would have been achieved is the unnecessary and confusing creation of a temporary array for no good purpose whatsoever.

Under slightly different circumstances, the use of chomp within the map could be considered a bad practice. On those occasions where that would be so, the reason for it being a "bad practice" have everything to do with sound, quantifiable, technical reasons...and nothing whatsoever to do with "style".

The purpose of my tongue in cheek analogy was to emphasis that your positioning a (sometimes valid) technical critique, under the banner of "style" was itself a dubious practice.

I might say, that your critique itself was "bad style", but then I'd be guilty of exactly the same sin as (IMO) you were.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!

it is very poor style to alter the input data in a map

Can you explain the reason behind this to me? I have never seen $_ localized inside of a map. I don't see why it's so bad to modify $_ inside the map. Unless you're maping through a list of references in which case you'd be modifying the original structure. I must admit to never having seen localized $_ in a map and that I've seen a million scripts that mangle $_ to death in such cases.

The Blue Camel has this to say about map on page 741:

Because $_ is an alias (implicit reference) into the list's values, this variable can be used to modify the elements of the array.

So you'll be modifying the orginal value, weather it was a list of references or not. Mearly chomping the value, as the code posted does, is unlikely to do real harm, so I wouldn't consider it a problem in this case.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Aha, I didn't realize that $_ was an alias within a map (greps as well then). Which makes a lot of sense if you take even half a second to think about it. I even threw together an example to prove it to myself.

# because $_ is an alias, @foo is also modified
my @foo = qw/one two three four five six/;
my @bar = map { s/[aeiou]//g; $_ } @foo;
print join(', ', @foo), $/;

# because we localize $_, @foo is not modified
my @foo = qw/one two three four five six/;
my @bar = map { local $_ = $_; s/[aeiou]//g; $_ } @foo;
print join(', ', @foo), $/;

# not to mention even when you loop through an array
my @foo = qw/one two three four five six/;
s/[aeiou]//g for @foo;
print join(', ', @foo), $/;
[download]

I thought that was common knowledge; guess not...

In any case, if the input list will not be used again after the map, i see no reason to create a local copy of $_.