Bug #59175 for Perl-Critic: policy object violation() method called in different package

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.

On Sun Oct 24 14:18:20 2010, clonezone wrote: 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(). 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.

"Tom Wyant via RT" <bug-Perl-Critic@rt.cpan.org> writes: Show quoted text
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.