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: 59175
Status: open
Priority: 0/
Queue: Perl-Critic

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

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



Subject: policy object violation() method called in different package
Date: Thu, 08 Jul 2010 07:48:44 +1000
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 412b
I created a violation object with $policy->violation from within a helper utilities package and found the resulting $violation object had its $violation->policy coming back as the utilities package, not the originating policy object's class. I see there's stuff in Perl::Critic::Violation->new using the caller package, but I hoped that $policy->violation on a policy object would not be afflicted by that :-).
Subject: Re: [rt.cpan.org #59175] policy object violation() method called in different package
Date: Sun, 24 Oct 2010 13:18:06 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 230b
Yeah, the problem here is that it was originally intended for Policies to call the constructor directly, so that hack was put in. We should probably deprecate that and switch to a _new() method that does things without the hack.
Download (untitled) / with headers
text/plain 1.5k
On Sun Oct 24 14:18:20 2010, clonezone wrote: Show quoted text
> Yeah, the problem here is that it was originally intended for Policies > to call the constructor directly, so that hack was put in. We > should probably deprecate that and switch to a _new() method that > does things without the hack.
Jeff and I have been kicking around named arguments for Perl::Critic::Violation->new(). It's easy to disambiguate a valid named call from a positional call because the former has at least 9 arguments (counting the invocant), but the latter only has 5, and the 5 is enforced by a throw_internal(). The Perl::Critic::Policy violation() method would use the named interface and pass a -policy argument, which would provide both the policy name (providing a response to this ticket, I think) and the severity. This eliminates the caller() hack. Because the P::C::P violation() method does _not_ validate its number of arguments, the plan is to create P::C::P make_violation(), which takes named arguments. All of this is in branch violation_named_args, where it will remain until _after_ the next release, unless you say otherwise. The incentive was actually another of Kevin's tickets, which asks for better reported line and column numbers for POD errors. The envisioned change here was to add arguments to the P::C::Violation() instantiator to allow tweaking of the position reported by PPI. The implementation is undefined. I am currently leaning away from fiddling with the position reported by PPI, because of the possibility of changing which Perl::Critic annotation (if any) applies to the element.
Subject: Re: [rt.cpan.org #59175] policy object violation() method called in different package
Date: Fri, 29 Oct 2010 10:02:10 +1100
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 963b
"Tom Wyant via RT" <bug-Perl-Critic@rt.cpan.org> writes: Show quoted text
> > Jeff and I have been kicking around named arguments for > Perl::Critic::Violation->new(). It's easy to disambiguate a valid named > call from a positional call because the former has at least 9 arguments > (counting the invocant), but the latter only has 5, and the 5 is > enforced by a throw_internal().
That sounds a touch subtle. I'd think hard about chucking optional args on the end of the existing call, Perl::Critic::Violation->new($desc, $expl, $elem, $sev, policy => $packagename, offset => ...); The policy could default to the caller as now. Except for the extra $sev arg it could be the same as the $policy->violation(). I suppose also possible would be a one-arg hashref of key/value bits. Personally I think I normally prefer a list of args instead of a hashref, but a hashref might be unambiguous in this case.


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.