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 mista

      • 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-based system, your entities perform various roles by inheriting from other classes which perform those roles, by composing in the behavior of various roles, by delegating specific activity to other entities which perform those roles, or by reimplementing part or all of the behavior encapsulated in the role. Obviously in the latter two cases you must explicitly declare that your entities perform those roles, but you do not compose in the behavior of those roles, at least in part.

        This has been an explicit design goal of the system from the very start.

        Roles should not and cannot dictate specific implementation details of entities which perform the roles, otherwise they're merely somewhat smarter mixins. It's nice to have somewhat smarter mixins -- they offer advantages -- but that has never been the sole point and goal of roles.

        The moment you throw a mandatory default warning on two of the four appropriate and specified uses of roles, you've penalized them. You're subtly encouraging people not to use the most important and most powerful features of roles! 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.

        It's difficult enough to convince people not to cram everything into a complex hierarchy without you strongly hinting that delegation and allomorphism are dangerous or complicated or prone to abuse.

        If that's your intention, by all means proceed -- but please be clear about it and don't justify your decision by pretending that the compiler can magically guess their intent, because we all know if it were true, we wouldn't even need roles.

        • 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.