Re^2: sub STDERR { *STDERR } -- nearly works !

...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.

Comment on Re^2: sub STDERR { *STDERR } -- nearly works ! Download Code

Replies are listed 'Best First'.
Re^3: sub STDERR { *STDERR } -- nearly works ! by ysth (Canon) on Apr 09, 2008 at 08:31 UTC
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. -- Online Fortune Cookie Search	[reply]
Re^4: sub STDERR { *STDERR } -- nearly works ! by gone2015 (Deacon) on Apr 09, 2008 at 10:32 UTC
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]