...not exporting variables...
see http://perldoc.perl.org/Exporter.html, at the end under Good Practices:
"Do not export variable names. Just because Exporter lets you do that, it does not mean you should."
and:
"Exporting variables is not a good idea. They can change under the hood, provoking horrible effects at-a-distance, that are too hard to track and to fix. Trust me: they are not worth it."
This section appears to be new in v5.10.0.
| [reply]
[d/l] |
I read that as saying you shouldn't compound the potential action-at-a-distance evil of having a package variable by allowing it to be referred to in other packages yet not qualified with the original package.
Which doesn't really apply to something exported from what sounds like a utility package intended to provide a "global" variable.
But since all packages share the same global $STDERR anyway, trying to export it is indeed a bad thing.
| [reply] |
Ah. It looked like one of those "between you and me it's a miracle this works, and sometimes it doesn't" sort of warnings !
Documentation http://perldoc.perl.org/perlmod.html says "In addition, when unqualified, the identifiers STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV, INC, and SIG are forced to be in package main , even when used for other purposes than their built-in ones."
But, it is now clear that I should have understood "unqualified" to mean "unqualified by a package name" (not "unqualified by any 'decoration'" -- doh!)
So I'll go away and stop worrying about it ! I don't need the export, and even if I did, it would be OK.
Thank you.
| [reply] |