in reply to Re: vs @ISA
in thread vs @ISA

Based on reading the thread you linked, and testing the code, this action-at-a-distance behavior can be avoided simply by using the module first.

From what I understand there are three major arguments against

  1. Hidden errors when a module cannot be found.
  2. Manipulation of fields (ala when it's not needed.
  3. Inability to pass a list to used modules.

Given that there are simple counters:

So, given all of that, what you're left with is a decision between:

use Module; use base qw(Module);


use Module; our @ISA = qw(Module);

I can tell you I prefer use base from a readability standpoint alone. It also has the advantage of assigning to @ISA at compile-time, instead of run-time, which can resolve some problems if the modules being used attempt to call class methods immediately. Admittedly, this is extremely rare, however.

If you are aware of any other outstanding problems with, by all means, share them. Otherwise what this boils down to is a simple style issue.

Replies are listed 'Best First'.
Re^3: vs @ISA
by diotalevi (Canon) on Oct 08, 2007 at 20:23 UTC

    You are also forgetting that it sets $VERSION for you if you haven't already done it. I found that incredibly confounding when working with some Inline::C code.

    $Your::Module::VERSION = '-1, set by';

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      Aha, so it does. How exactly did it confound you?

        Inline::C compiled a .so file with the version 0.00 while the perl was '-1, set by'. DynaLoader expects the two to match and throws an error if they don't but Inline was hiding it so I had to dig deeply to watch the error come up.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊