Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > reason for local($_) ?

Reply
Thread Tools

reason for local($_) ?

 
 
Tim McDaniel
Guest
Posts: n/a
 
      04-03-2012
This thread was about a project where every sub was started with
local($_);

In article <adc97$4f7b61e1$813f0835$(E-Mail Removed) >,
<(E-Mail Removed)> wrote:
>At the end of the day Randal is correct, I believe. The author of the
>code in question was just blindly adding that line for more or less
>uninformed and superstitious reasons.


I'll disagree, because what's also consistent with the evidence is
"better safe than sorry, prevent an accidental while(<$sth>) or other
place here stomping $_".

--
Tim McDaniel, http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Ted Zlatanov
Guest
Posts: n/a
 
      04-04-2012
On Tue, 3 Apr 2012 21:41:44 +0000 (UTC) (E-Mail Removed) (Tim McDaniel) wrote:

TM> This thread was about a project where every sub was started with
TM> local($_);

TM> In article <adc97$4f7b61e1$813f0835$(E-Mail Removed) >,
TM> <(E-Mail Removed)> wrote:
>> At the end of the day Randal is correct, I believe. The author of the
>> code in question was just blindly adding that line for more or less
>> uninformed and superstitious reasons.


TM> I'll disagree, because what's also consistent with the evidence is
TM> "better safe than sorry, prevent an accidental while(<$sth>) or other
TM> place here stomping $_".

My personal approach to $_ is very simple. It follows from two of the
fundamental laws of programming: Know What The Hell Is Going On; and
Life's Too Short To Chase Bugs You Could Have Avoided.

If I know where $_ came from and can *see* the lines of code that
generated $_, I use $_. So a tight loop or a small block is OK. Never,
ever would I use $_ inside a function, hoping it's OK. Regardless of
the optimization, it's just begging a bug report later.

If I don't know if it may have changed, I switch to using a variable.
It's very important not to be lazy about this switch. Usually for me it
happens when the loop or code block exceeds 3 lines or calls a function.

I thus never have to use "local $_" because I KWTHISGO (hopefully, I say).

And I choose to avoid relying on $_ because LTSTCBYCHA.

Hope that helps...
Ted
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      04-04-2012
(E-Mail Removed) (Tim McDaniel) writes:
> In article <adc97$4f7b61e1$813f0835$(E-Mail Removed) >,
> <(E-Mail Removed)> wrote:
>>At the end of the day Randal is correct, I believe. The author of the
>>code in question was just blindly adding that line for more or less
>>uninformed and superstitious reasons.

>
> I'll disagree, because what's also consistent with the evidence is
> "better safe than sorry, prevent an accidental while(<$sth>) or other
> place here stomping $_".


If you don't know what the code at deeper levels in the call tree is
going to do, how can you be sure that it won't intentionally try to
change 'the global $_'? It is already a bad idea to add code to work
around real bugs in other code and fixing these is always
preferrable (the long-term cost of 'a ****ing mess' is usually severly
underestimated when being compared it with the short term cost of
'adding another quick & dirty hack, no time to solve the actual
problem now' ...). It is a really bad idea to add technically useless
code to work around hypothetical errors in other code.

 
Reply With Quote
 
Tim McDaniel
Guest
Posts: n/a
 
      04-04-2012
In article <(E-Mail Removed) >,
Rainer Weikusat <(E-Mail Removed)> wrote:
>(E-Mail Removed) (Tim McDaniel) writes:
>> In article <adc97$4f7b61e1$813f0835$(E-Mail Removed) >,
>> <(E-Mail Removed)> wrote:
>>>At the end of the day Randal is correct, I believe. The author of the
>>>code in question was just blindly adding that line for more or less
>>>uninformed and superstitious reasons.

>>
>> I'll disagree, because what's also consistent with the evidence is
>> "better safe than sorry, prevent an accidental while(<$sth>) or other
>> place here stomping $_".

>
>If you don't know what the code at deeper levels in the call tree is
>going to do, how can you be sure that it won't intentionally try to
>change 'the global $_'?


Indeed it could, and thank you for pointing it out. If it is possible
for a callee to change a value in a caller, one of the two should save
values and restore them at the end. For example, in the IBM
System/370 architecture, a subroutine caller must set four registers,
but the callee is responsible for saving and restoring all other
registers.

It's a lot more practical for a callee to protect $_, because it
happens once at the top of the sub instead of every caller potentially
having to protect $_ on every call it makes in a $_-using scope.
I've been assuming that subs preserve $_. Then again, my orkplace
uses the convention that sub names that start with an underscore are
supposed to be private and not called outside the source file, but
I've seen it happen nonetheless.

I'm thinking that lexical $_ is looking better and better, even with
the problem with map {} and grep {}.

--
Tim McDaniel, (E-Mail Removed)
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      04-05-2012
On 2012-04-04 14:30, Rainer Weikusat <(E-Mail Removed)> wrote:
> (E-Mail Removed) (Tim McDaniel) writes:
>> In article <adc97$4f7b61e1$813f0835$(E-Mail Removed) >,
>> <(E-Mail Removed)> wrote:
>>>At the end of the day Randal is correct, I believe. The author of the
>>>code in question was just blindly adding that line for more or less
>>>uninformed and superstitious reasons.

>>
>> I'll disagree, because what's also consistent with the evidence is
>> "better safe than sorry, prevent an accidental while(<$sth>) or other
>> place here stomping $_".

>
> If you don't know what the code at deeper levels in the call tree is
> going to do, how can you be sure that it won't intentionally try to
> change 'the global $_'?


You don't. The local($_) doesn't protect this function from its callees,
it protects the the callers from this function. It promises to the
caller that it won't modify $_.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Bill Code on (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
802.1x EAP type setting changes for no reason J. Marc Roth Wireless Networking 0 03-22-2005 01:21 AM
Wireless network lost file sharing for no reason =?Utf-8?B?VG9n?= Wireless Networking 1 12-31-2004 01:17 PM
Any reason not to delete IE and OE from hd? tenplay Firefox 5 06-28-2004 02:43 AM
reason for migration from Mozilla 1.6 to Thunderbird? Wolfgang Kern Firefox 1 05-24-2004 12:05 PM
Re: Compilation error reason??? Weng Tianxiang VHDL 1 07-24-2003 03:08 PM



Advertisments