These "rules" do have exceptions sometimes. In my view, the point of "use @EXPORT_OK instead of @EXPORT" is to avoid cluttering up the user's namespace, and also to provide a bit more readability: use Config '%Config'; would tell the reader of the code exactly what is being exported, use Config; doesn't. I know some might disagree, but IMHO, some modules are so single-purpose that it's ok to export maybe one or two things by default, if their names won't lead to confusion (e.g. the name of the thing they export is traceable back to the name of the module). IMO, Config is such a single-purpose module, so it's ok to export %Config by default. Also, %Config is read-only, so "[the variables] can change under the hood, provoking horrible effects at-a-distance that are too hard to track and to fix" doesn't apply here either.
More exceptions might be: some modules exist for the explicit purpose of exporting a bunch of functions (e.g. to reduce boilerplate), and I also think it's sometimes acceptable to export certain variables on request (e.g. in a test script I might provide something like $DEBUG, where the fact that this is a global variable is not a problem).
In reply to Re: Why does Config.pm break the rules?
by haukex
in thread Why does Config.pm break the rules?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |