In Minnesota election results watcher you write:
main(); exit; # ... sub main { # ... 1; }
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;
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 );
(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
In reply to Re^4: Problem with "use Exporter qw(import);"
by tye
in thread Problem with "use Exporter qw(import);"
by johnnywang
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |