Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • [When] the computer can find potential problems -- particularly when it's close to compile time -- this is far better than requiring the programmer to always look for those potential problems.

    This is not a case where the computer can identify problems with certainty. The compiler cannot judge your intent. Did you make a typo in the name of a class-local method such that it collides with the name of a composed method? Did you forget to read the documentation? Did you do it deliberately? Did someone up

    • Imagine if Perl warned every time you slurp a file into an array. Sometimes that's a mistake -- perhaps often, it's a mistake. It's not always a mistake.

      Imagine if Perl warned you every time you used a package-scoped variable only once. Sometimes that's a mistake -- perhaps often, it's a mistake. It's not always a mistake.

      Imagine if Perl warned you every time you redefined a function (for example to memoize or inline it). Sometimes that's a mistake -- perhaps often, it's a mistake. It's not always a mistake.

      Imagine if Perl warned you every time you recursively called a function more than 100 times.

      Every time you used comma in a qw//.

      Every time you leave an eval with next.

      Every time you use @{ } or %{ } on a variable that happens to share a name with a builtin.

      Every time you include some code directly after an exec call, so you can throw a proper error if the exec fails.

      It's a wonder why anyone ever turns on these bothersome warnings. Some modules even have the gall to enable them for me without my explicit permission.

      enable an optional warning

      I encourage you to read this insightful blog post [modernperlbooks.com] about why optional warnings are short-sighted. It is every bit as accurate when its subject is swapped for Moose.

      * * *

      Please don't take this the wrong way, chromatic. I respect you, your writing, and your contributions to free software. I just tire of this outrage over a warning whose purpose is to help users write more maintainable and clear code. "No surprises" is a laudable goal not only during release, but also between releases.

      • I encourage you to read this insightful blog post [modernperlbooks.com] about why optional warnings are short-sighted.

        I call: The Value of a Warning [modernperlbooks.com].

        If you believe that the only purpose of roles is compile-time, warning-safe mixins, you're missing at least half of their power.

        The purpose of roles -- the real, get your hands dirty, oh wow this is an epiphany moment of roles -- is to produce a type system that tracks the capability of entities without dictating their particular implementation of those capabilities.

        In a true role

        • You're actively discouraging people from taking advantage of allomorphism using well-established and long-recommended design techniques explicitly made safer and more understandable by roles.

          I responded at my blog [blogspot.com] with a description of both sides of the argument. The gist of it is: the warning is gone, and we will support the warning Ovid needs (and much more) as Perl::Critic policies.