use Perl

• Importing (Score:2)

  by Ovid (2709)

  * 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
  • Re: (Score:2)

    by drhyde (1683)

    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.
  • Re: (Score:2)

    by schwern (1528)

    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?
• The $VERSION "issue" (Score:1)

  by Adrian (66)

  * 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)
• Re: base.pm (Score:1)

  by rjbs (4671)

  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
• Bogus argument (Score:1)

  by Corion (7288)

  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
  • Re: (Score:2)

    by schwern (1528)

    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.