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.

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.

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.

Perhaps you are missing a "not" and/or a subject somewhere in there? I can't decipher what you mean.

In a more normal module, what you wrote would be flat-out incorrect code.

Importing is importing. Perl5 doesn't distinguish between methods and subroutines. You can import methods and use them as methods. You can import functions and use them as functions. You'll have to be more specific about what you think won't work about this.

Which version is *import = \ &Exporter::import kosher in anyway?

I'm not aware of any version of Exporter.pm where this fails. I certainly haven't had any problems with it and have practiced it for quite a long time. Years ago I noticed a comment saying that some corner cases might not work w/o @ISA being set, but I've never run into such a case.

I didn't see a mention of this use of the API in even the 5.8.5 documentation on search.cpan.org.

There wouldn't be much point in me suggesting that it should be added to the documentation if it were already there.

- tye