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 had the impression from reading your node that the option to import the import function wasn't so much a significant change to Exporter.pm as much as it was a happy coincidence that importing the import function worked correctly instead of using inheritance. I also didn't have much reason to re-read Exporter's documentation since the API hadn't changed in any way.

What originally wrote didn't look correct and it only now occurrs to me that this form of importing wouldn't normally work because import is always called as a class method anyway. In a more normal module, what you wrote would be flat-out incorrect code. Thinks would still work if you did this in normal code but I've never seen anyone seriously advocate for flattening inheritance trees to avoid recursive @ISA lookups in this particular way.

Which version is *import = \ &Exporter::import kosher in anyway? I didn't see a mention of this use of the API in even the 5.8.5 documentation on search.cpan.org.

  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.

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

If you're running mod_perl with any sizable set of modules, Exporter is almost certain to be pre-loaded by something else.

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