Re: Re: Using $_ as a temp var, especially in functions

I would tend to turn that statement around and say that if your code relies on $_ at a higher level, and clobbering it at a lower level results in chaos, then you shouldn't be using $_ at the higher level.

It is not that easy. Clobering $_ at a lower level can easily break map, for/foreach and grep constructs at a higher level as shown at this topic: while(<>) { ... } considered harmful.

In short: would you rewrite code like

my @result = map some_sub($_), qw(a b c d);
[download]

my @result = map { my $x = $_; local $_; some_sub($x) } qw(a b c d);
[download]

to satisfy your requirement?

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

Comment on Re: Re: Using $_ as a temp var, especially in functions Select or Download Code

Replies are listed 'Best First'.
Re:x3 Using $_ as a temp var, especially in functions by grinder (Bishop) on Oct 23, 2002 at 13:19 UTC
If I had the chance, I would rewrite `some_sub` to work on lists, which would allow me to say `my @result = some_sub(qw(a b c d));` But I will grant you that that is a somewhat facetious answer, as I understand your question to mean an arbitrarily complicated map code block and not something as simple. But then were the map code block arbitrarily complicated, I would no longer be using map, but instead I would be using for, which would make the code look like: `my @result; for my $thing(qw(a b c d)) { # complex code block that munges $thing followed by push @result, $thing; }` [download] On the Principle of Least Surprise, by and large I tend to put unsurprising code in maps and greps. That rules out function calls and other invisible things that might play around with $_. for blocks do not suffer from these problems because you can name your own topicalizer (or whatever it's called) with the `for my $topic` construct. If you stick to this, you can't be bitten by the types of problems you describe. `<update>` if you have code running around secretly overloading the + operator, then clobbering $_ is likely the least of your problems. Just because you can write code that dicks around with $_, doesn't mean you should. We'll just have to agree to disagree. Your point is valid and I find no fault with it, I just see things differently.</update> print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'	[reply] [d/l] [select]
Re: Re:x3 Using $_ as a temp var, especially in functions by IlyaM (Parson) on Oct 23, 2002 at 13:49 UTC
That rules out function calls and other invisible things that might play around with $_. Unfortunately in Perl nearly everything can do invisible things that might play around with $_. You think something like `$x + $y` is safe? Wrong if $x is an object that overloads '+' operator. Or do you think that, say, hash access is safe? Again it may be not if hash is tied. Besides to my taste map and grep constructs often are much more ideomatic than corresponding for construct that I simply don't want to rule out function calls because my code will be less pretty. In my opinion there is no excuse for not localizing $_ in a low level code. -- Ilya Martynov, ilya@iponweb.net CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org	[reply] [d/l]
Re: Re: Re:x3 Using $_ as a temp var, especially in functions by IlyaM (Parson) on Aug 07, 2003 at 07:34 UTC
Or do you think that, say, hash access is safe? Again it may be not if hash is tied. What is demonstrated in Method call to tied hash leads to file read error. -- Ilya Martynov, ilya@iponweb.net CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks