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 base.pm:

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

Given that there are simple counters:

• Use the module prior to passing it to use base. This solves both 1 and 3.
• The fields manipulation is conditional, based on whether or not fields have been manipulated prior. If you don't need fields, base.pm won't do anything to them.

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

    use Module;
    use base qw(Module);
[download]

and:

    use Module;
    our @ISA = qw(Module);
[download]

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 base.pm, by all means, share them. Otherwise what this boils down to is a simple style issue.

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 base.pm.';

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

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