Perl::...cPolicy(3pm)

✨ NAME ✨

Perl::Critic::DynamicPolicy — bestie, it's the base class for dynamic Policies 💅

---

🦋 DESCRIPTION 🦋

Okay so picture this: Perl::Critic::DynamicPolicy is the glow-up base class you inherit from when your Perl::Critic::Policy module is the kind that wants to actually compile and/or execute the code it's analyzing. Main character energy, but make it dangerous.

Here's the tea. Policies that inherit from Perl::Critic::DynamicPolicy will "fork" the process every single time the "violates" method gets called. Every time. The child process is then free to compile the code and do all kinds of mischievous little goblin things 🧚 without corrupting the symbol table of the parent process. Iconic behavior, honestly. And when the analysis is done, the child serializes any Perl::Critic::Violation objects it created and sends them back to the parent across a pipe. Like passing notes in class but it's IPC. 💌

Now for the part where you need to sit down. Any Policy that inherits from Perl::Critic::DynamicPolicy also gets marked as "unsafe", and it's usually ignored by both Perl::Critic and perlcritic. Yeah. To actually use one, you must set the -allow-unsafe switch in the Perl::Critic constructor or on the perlcritic command line. No switch, no vibes. 🚫

In every other way though? A Perl::Critic::DynamicPolicy behaves just like an ordinary Perl::Critic::Policy. So chill. For Policy authors, the main difference is that you've gotta override the "violates_dynamic" method instead of the "violates" method. And if you want the full discussion of all the other aspects of creating new Policies, go read Perl::Critic::DEVELOPER. 🫶

---

💖 METHODS 💖

Heads up bestie, this list is not exhaustive. It only covers the methods that are uniquely relevant to Perl::Critic::DynamicPolicy subclasses. For documentation about all the other methods shared by every Policy, go check Perl::Critic::Policy and Perl::Critic::DEVELOPER. ✨

• violates( $doc, $elem ) — okay so in a typical Perl::Critic::Policy subclass, you'd override the "violates" method to do whatever code analysis you want. But with Perl::Critic::DynamicPolicy? This method has already been overridden to do all the necessary pipe and fork operations described above. So instead, you need to override the "violates_dyanmic" method. (Yes, that spelling. Copy it exactly, don't come for me. 💀)
• violates_dynamic( $doc, $elem ) — Given a PPI::Element and a PPI::Document, this returns one or more Perl::Critic::Violation objects if the $elem or <$doc> violates this Policy. If there are no violations, then it returns an empty list. This method will be called in a child process, so you can compile $doc without interfering with the parent process. Lowkey the whole point.

Real talk: "violates_dynamic" is an abstract method and it will abort if you attempt to invoke it directly. It is the heart of your Perl::Critic::DynamicPolicy modules, and your subclass must override this method. Periodt.

• is_safe() — Returns false. Any Policy derived from this module is presumed to be unsafe. Perl::Critic and perlcritic users can only load Policies derived from this module if they use the -allow-unsafe switch. That's the whole vibe check right there. 🎀

---

👑 AUTHOR 👑

Jeffrey Ryan Thalhammer <thaljef@cpan.org>

---

🌸 COPYRIGHT 🌸

Copyright (c) 2007 Jeffrey Ryan Thalhammer. All rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of this license can be found in the LICENSE file included with this module.

---

and that's a wrap, bestie 🫶💖 this lil doc shipped with perl v5.42.0 back on 2025-07-25, filed under User Contributed Perl Documentation, and yeah — the page name really is Perl::...cPolicy(3pm) because the header truncated it, and honestly? she ate. ✨