Using inheritance to get one function is quite overkill. I've had my share of problems from such things. Better is to just import the one import function you want. Unfortunately, old versions of Exporter.pm didn't support the easy way of doing this. I just use:

require Exporter;
*import = \&Exporter::import;
[download]

You can even put those two lines inside of a BEGIN block if you like.

If I read that I'd have to wonder what bug the author was trying to work around. Your example is pretty non-standard as far as ways of including Exporter go. I hope this doesn't constitute "normal" code for you or that you at least comment why you chose to write it so oddly.

In Minnesota election results watcher you write:

main();
exit;

# ...

sub main {
  # ...
  1;
}
[download]

Exactly which bugs are you trying to avoid with such oddness? Could you please list them all out explicitly whenever you write such code?

When I write:

require Exporter;
*import = \&Exporter::import;
[download]

I am trying to pull in exactly one function from a module. That is just plain the most straight-forward way of doing that. Given the option, I'd prefer to write that as:

require Exporter qw( import );
[download]

(which is simpler in some ways but more indirect in others, hence not as straight-forward, since I'd have to investigate whether Exporter.pm's import exports itself in the usual way) but this isn't an option for me (I don't live in a world where I can guarantee that perl 5.8 or whatever is being used).

I avoid inheritance unless I have a good reason not to. I don't list out the reasons why I avoid inheritance at every place that I avoid inheritance. That would be odd.

Your example is pretty non-standard as far as ways of including Exporter go.

That standard way was to inherit. The new way is to import import().

If you'd like to learn about why Exporter.pm was changed so that you can import import() instead of inheriting, then I suggest you search for information on the history of Exporter.pm rather than expect me to justify such things every time I use Exporter.pm in the least-error-prone way that I know of.

It makes a lot more sense to update the documentation of Exporter.pm to note a third way to use it that has the best of both of the options that are currently listed (avoids the pitfalls of overuse of inheritance but still works on old versions of Exporter.pm). I think that would be a much more useful place for such comments to be added.

- tye        

I'm partial to writing this using goto, which lets us defer the loading of Exporter until we actually need it.

  sub import { require Exporter; goto &Exporter::import }
[download]

Caveat - you actually want to pre-load Exporter when using mod_perl and similar persistent architectures.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

I've had my share of problems from such things.

Could you give an example or two? I've used use base 'Exporter'; for a while; should I be avoiding that?