Click here to get back home

Relying on $_
 Home | NewsGroups | Search | About
Login Password
Register Now!
 comp.lang.perl.misc    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Relying on $_ Bernie Cosell 01-24-2008
Get Chitika Premium
Posted by Bernie Cosell on January 24, 2008, 12:15 pm
Please log in for more thread options
 As a matter of style and expectation, I'm wondering about relying on $_.
Often, just for convenience I'll do a no-var foreach. For example:
foreach (sort keys %SOMEHASH)
{ print "Processing $_\n" ;
my $target = $SOMEHASH ;
....
}
and I'll refer to $_ here and there in the loop [e.g., if something fails
I'll typically just do a 'die "Error processing $_: $!\n" ;' or the like].
Is that bad form? I just sorted out a minor problem where I was calling an
object method and I was surprised to discover that $_ was clobbered when I
got back from the method.

Is this a bug [even if a minor one] in the package? If not, what are the
rules for when you should and shouldn't expect $_ to get messed up?

/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--

Posted by smallpond on January 24, 2008, 12:58 pm
Please log in for more thread options
> As a matter of style and expectation, I'm wondering about relying on $_.
> Often, just for convenience I'll do a no-var foreach. For example:
> foreach (sort keys %SOMEHASH)
> { print "Processing $_\n" ;
> my $target = $SOMEHASH ;
> ....
> }
> and I'll refer to $_ here and there in the loop [e.g., if something fails
> I'll typically just do a 'die "Error processing $_: $!\n" ;' or the like].
> Is that bad form? I just sorted out a minor problem where I was calling an
> object method and I was surprised to discover that $_ was clobbered when I
> got back from the method.
>
> Is this a bug [even if a minor one] in the package? If not, what are the
> rules for when you should and shouldn't expect $_ to get messed up?
>

It is almost never a good idea to use $_ (or $a or $b) as
the loop variable in a foreach. see perltrap and perlvar.
"my $key" is quite reasonably priced and doesn't
get clobbered by subs that you call.

The rule is pretty simple: there's only one $_ in your
package, and there are many functions that use it implicitly.
Many subs should have local $_ but don't, so it is never good
to assume it will be preserved across a call.

The other thing to remember about foreach is that it creates an
alias for the value, not a copy.

Posted by Michele Dondi on January 25, 2008, 6:03 am
Please log in for more thread options
On Thu, 24 Jan 2008 12:15:57 -0500, Bernie Cosell

>As a matter of style and expectation, I'm wondering about relying on $_.
>Often, just for convenience I'll do a no-var foreach. For example:
> foreach (sort keys %SOMEHASH)
> { print "Processing $_\n" ;
> my $target = $SOMEHASH ;
> ....
> }
>and I'll refer to $_ here and there in the loop [e.g., if something fails
>I'll typically just do a 'die "Error processing $_: $!\n" ;' or the like].
>Is that bad form? I just sorted out a minor problem where I was calling an

IMHO, it's all a matter of how long the actual for block is. As far as
I'm concerned, I use $_ if it is *at most* say ten lines of code or
so.

>object method and I was surprised to discover that $_ was clobbered when I
>got back from the method.

Then that method was doing something very Bad(TM) i.e. manipulating $_
directly.


Michele
--
->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Posted by Ted Zlatanov on January 25, 2008, 1:22 pm
Please log in for more thread options

BC> As a matter of style and expectation, I'm wondering about relying on $_.
BC> Often, just for convenience I'll do a no-var foreach. For example:
BC> foreach (sort keys %SOMEHASH)
BC> { print "Processing $_\n" ;
BC> my $target = $SOMEHASH ;
BC> ....
BC> }
BC> and I'll refer to $_ here and there in the loop [e.g., if something fails
BC> I'll typically just do a 'die "Error processing $_: $!\n" ;' or the like].
BC> Is that bad form? I just sorted out a minor problem where I was calling an
BC> object method and I was surprised to discover that $_ was clobbered when I
BC> got back from the method.

BC> Is this a bug [even if a minor one] in the package? If not, what are the
BC> rules for when you should and shouldn't expect $_ to get messed up?

I'd say if there's more than two lines of code in the loop code, don't
use $_. It is very handy for map/grep/postfix-foreach loops but can
make life hell otherwise.

Ted

Posted by Ben Morrow on January 25, 2008, 5:40 pm
Please log in for more thread options

> On Thu, 24 Jan 2008 12:15:57 -0500 Bernie Cosell
>
> BC> As a matter of style and expectation, I'm wondering about relying on $_.
> BC> Often, just for convenience I'll do a no-var foreach. For example:
>
> BC> Is this a bug [even if a minor one] in the package? If not, what are the
> BC> rules for when you should and shouldn't expect $_ to get messed up?
>
> I'd say if there's more than two lines of code in the loop code, don't
> use $_. It is very handy for map/grep/postfix-foreach loops but can
> make life hell otherwise.

This is probably an appropriate time to point out 5.10 has a lexical $_:

~% perl5.10.0 -E'
sub foo { say shift; $_ = 1; }
my $_; foo $_ for 2, 3, 4;
'
2
3
4

Ben



Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap