However, I'd personally do neither of those. The best way these days to declare inheritance is use base, which also has the handly property of being a compile-time construct.

As a result, you may have to reorder the definition for your packages and possible even add a $VERSION variable (in an inline package!). All that to please base. Yuck.

I wish we could bypass the magic, and explicitely tell it to load a module, or just skip that phase.

If it wasn't for that annoyance, base would indeed work very well, for the reasons you give.

That's interesting - and serves as an additional data point that consensus on current perl OO "best practice" is a bit limited at the moment. Yes, TIMTOWDI, but that can be confusing for newcomers.

Do you think that these tutorials are still current? (Actually, I should have linked to these at first, sorry about that).

By the way, would you care to elaborate on base's failure modes? Since you've caused me to look more closely, I can see how it might hurt if you're defining a module inline with the same name as one available as a seperate file via require - is that the main issue?

I'm not sure how base has evolved over the years, but I've had problems where it died complaining it couldn't locate a module where the package was inline in the script further down, and it may indeed load an unwanted module of the same name (B is a favourite example) under similar circumstances. Fun for the whole family.

Checking $VERSION in a package, to check if the package exists, is not the best way to tackle the problems, IMO.

IMO base is a crap module, it tries to handle both loading external files and inline packages, but it tries Too Much Magic™ and in some cases it may fail. It's failed many times for me in the past. I don't trust it any more.

Use it all the time. Never had a problem with it :-)

I don't really think it's that magical. Two rules:

• If the package is already loaded - use it
• Otherwise, try and use it.

Well, require is for loading files, which you won't need at all if everything is inline, so removing it is a good idea.

The reason I would prefer 'use base' (bart's objections notwithstanding) over assigning directly to @ISA is that I don't like having run-time code in modules. (It also seems to work fine in a test here - just remove the @Class2::ISA line and use base qw/Class2/; instead of require Class2;).

I would say that having a script with a single entry point and execution following function/method invocation, it is easier to see what is going on. Otherwise one must read through the whole file to check for side-effects.

For example, I commonly have a

main</c< function:
<code>
#!/usr/bin/perl
use warnings;
use strict;

exit !main(@ARGV);

sub main {
  ...
}

sub foo {
}
[download]

The benefit of the early exit is that a maintainer can see that there isn't any run-time code lurking down between any later subs (since execution never flows down there). It also means that any lexical variables I use in main aren't accidentally accessible in the functions within the script. (OK, it might make sense to have some file-scope vars, but such things should stand out, not be the default because I'm writing code at the toplevel).

Yes, for quick scripts etc it is handy to have the scripting behaviour, but by the time we bring OO or helper functions in, we probably have enough complexity that this kind of discipline is beneficial.

So...when using perl as a programming language (as opposed to a 'scripting' language), I think it is harmful to have code at the top-level - it's effects are too wide-spread (variable scope too large) and the code can be spread over too large an area to see easily.