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.
  • The policy in question comes from Perl-Critic-Tics, which describes itself as: The Perl-Critic-Tics distribution includes extra policies for Perl::Critic to address a fairly random assortment of things that make me (rjbs) wince.

    In other words: it's things that I don't want to see in my code. If you want to be like me, swell.

    I don't think any of the things I listed are *bugs*, they're just things that *I don't like*.

    "You shouldn't be importing functions from a superclass." Wishing doesn't make it so. In the cases where this is practical, I will end up saying "use Baseclass (...); BEGIN{@ISA = 'Baseclass';}" Now maybe I am going to use base elsewhere. Did I use it first? Well, now I clobbered ISA. So I need to remember to use base second or, if I need to use things first, I need to push to @ISA. Or I could just not ever use base, and then I will not have to worry about this.

    To enforce this, maybe I'll write a Perl::Critic policy and put it in my private collection of them. Not only will I help myself write better code, I'll get to start a lively discussion about how I'm a bitcher and not a do-er!

    I agree that people would complain if base replaced ISA. Its current behavior is well documented and well established. That's why I don't want to use it: changing it would probably be more annoying to everyone involved than adding some goofy method to say "set, don't push."

    By not using base.pm, I minimize the ways in which I am likely to confuse myself.

    I admit that my comment about fields is a red herring. What I don't like is the fact that it deals with fields at all, not that it has X amount of code. I don't like it because it has to be documented. If a novice programmer is looking at my code and sees that it uses "base," he may not know what base is and will consult the documentation. The documentation will talk about fields, which sound like some sort of basic and important thing for classes, but are not. Despite this, neither base nor fields says, "please don't use me, because we are from another planet." Is this a nit pick? Sure. It's just one more little reason that I don't see much value in using base in my code.

    It's nice that base.pm easily moves ISA-setting and module requirement into one statement at compile time. I am aware of the need to do this, though, and I can put it in a BEGIN block. I do not worry about remembering this, because I'm familiar with the need to do so. I'm less likely to remember that I made a decision to stop using base.pm, which is why I wrote a policy for that, and not a policy to make sure that @ISA is only set during compile time.

    As per your request, I have filed tickets. I only thing one of them is much of a bug. It's the one you seem to know nothing about, so I am sorry that I didn't report it the first time it annoyed me.

    http://rt.cpan.org/Ticket/Display.html?id=28579 [cpan.org]
    --
    rjbs