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.
  • * You shouldn't be importing functions from a superclass and nobody's stopping you from adding a "use Baseclass" if you really want to.

    True, but it's frustrating to inherit from a base class which might need arguments passed to its import method. There was some discussion about this on P5P and I recall someone suggesting something like this:

    use base
      'SomeClass',
      'SomeOtherClass' => { import => [ qw/import args/ ] };

    That would be backwards compatible and get around that limitation

    • Also import() isn't just used to, umm, import. It's quite a common idiom to use it to pass global settings to a class, such as telling it to put temporary files in a particular place, or changing its default timezone. Those still have their place in OO programming.

      Even so, I don't consider this to be a problem with base.pm. If I really need to do things like that, the work-around is trivial.

    • Here's what I expressed on p5p: 80% of the code and syntax will be devoted to a feature that you use 1% of the time and has a perfectly reasonable work around that everyone understands. Just not worth the extra work/complexity/documentation/bugs.


              use base qw(Foo);
              use Foo qw(some args);


      And isn't it "let's add just one more feature" that got base.pm in this situation in the first place?
  • * I don't know what people are talking about screwing with $VERSION.

    Not that I think it's a problem - but I think folk are referring to base setting VERSION to '-1, set by base.pm' if it's undef.

    Adrian (thoroughly in the "liking base" camp)

  • 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
    --
    rjbs
  • Yes, C should be using A but I've read a lot of commercial code that just assumes other modules are loaded and its a horrible thing to debug.

    What a bogus argument. I would accept this if you had said "I have written a lot of commercial code that just assumes ...", but arguing a (unremovable, by now) misfeature of your code as something actually beneficial is quite a stretch. I hadn't looked at the source code of base.pm before people argued against it, but for my taste it is far too close to the code of

    • I think we're having a violent agreement. My example about the commercial code was illustrating the importance of inheriting at compile time vs setting @ISA at run time. All the other details of "use base" are orthogonal.

      Some people remember to put a BEGIN around setting @ISA (and @EXPORT) but most don't either because they forget or aren't aware.