in reply to Why does Config.pm break the rules?
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).
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Why does Config.pm break the rules?
by NERDVANA (Priest) on Feb 17, 2023 at 17:17 UTC |