Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 46971
Status: open
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: ProhibitLocalVars on localized hash entry
Date: Tue, 16 Jun 2009 07:52:34 +1000
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 545b
I've had some success using "local" to make block-scoped hash value settings, like flags on an object for recursion protection etc, { local $self->{'update_in_progress'} = 1; ... } It'd be good if ProhibitLocalVars allowed expressions like that (array element, hash element, other sorts of dereference), on the basis the aim of the policy is to pick up places which ought to be "my" instead of "local". (Or alternatively, if the above is a bad idea then further notes in the docs about why the policy is flagging it ...)
Index: ProhibitLocalVars.run =================================================================== --- ProhibitLocalVars.run (revision 3341) +++ ProhibitLocalVars.run (working copy) @@ -27,6 +27,8 @@ local $SIG{HUP} \&handler; local $INC{$module} = $path; +local $self->{'update_in_progress'} = $path; + #----------------------------------------------------------------------------- ##############################################################################
Subject: Re: [rt.cpan.org #46971] ProhibitLocalVars on localized hash entry
Date: Mon, 22 Jun 2009 15:32:09 -0400
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 646b
Kevin Ryde via RT wrote: Show quoted text
> I've had some success using "local" to make block-scoped hash value > settings, like flags on an object for recursion protection etc,
Interesting. I never thought about applying "local" to a lexical hash reference. I've localized individual values in a global hash before, of course, but never in a lexical one. I'm thinking that the current behavior should still be the default, simply to discourage use of local by those who don't know what's going on, but assuming that you do know what it's doing, I see no reason to complain about it. So, I think we should have an option for this to turn this situation off.
Subject: Re: [rt.cpan.org #46971] ProhibitLocalVars on localized hash entry
Date: Thu, 25 Jun 2009 09:38:04 +1000
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 421b
"Elliot Shank via RT" <bug-Perl-Critic@rt.cpan.org> writes: Show quoted text
> > I think we should have an option for this to turn this situation off.
I shouldn't think anyone could write "local $foo->{...}" without meaning it, it couldn't be a mistaken "my"; so I wouldn't worry about an option. Perhaps keep it nice and narrow though, just a hash or array dereference ie. local $foo->..., initially if you like, and see how that goes.
Subject: Re: [rt.cpan.org #46971] ProhibitLocalVars on localized hash entry
Date: Thu, 25 Jun 2009 07:44:13 -0400
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 442b
Kevin Ryde via RT wrote: Show quoted text
> "Elliot Shank via RT" <bug-Perl-Critic@rt.cpan.org> writes:
>> I think we should have an option for this to turn this situation off.
> > I shouldn't think anyone could write "local $foo->{...}" without meaning > it, it couldn't be a mistaken "my"; so I wouldn't worry about an option.
You don't? What fantasy island do you live on? I guarantee you that beginners get mixed up between my and local all the time.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.