in reply to Re: Using $_ as a temp var, especially in functions
in thread 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]

to

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

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]
      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]
[reply]

In Section Meditations