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.
