I don't want to join the discussion in general, and I'm not on the
language list. So this is a one-shot manifesto.
I agree with the goal of RFC17:
Organization and Rationalization of Perl State Variables
but I think the implementation ideas are making a terrible mistake.
Specifically:
> =head1 IMPLEMENTATION
> =head3 Well-Named Global Hashes And Keys
I think if there's one thing we have learned (or should have leanred)
from Perl 5, it's that this sort of global state variable is a
terrible idea regardless of what its name is.
Why is $* deprecated? Because it's dangerous.
Why is $* dangerous?
Because some function eleven calls down in some module you never heard
of that was loaded by some other module might do this:
$* = 1;
which suddenly changes the semantics of *every* regex match in your
*entire* program.
Conclusion: The real problem with $* isn't the name (although the
name is nasty.) The real problem is that it's a global variable with
a global effect, and it changes the meaning of code that is far away.
RFC17 fixes the little problem and leaves the big problem gaping and
festering.
But OK, $* is deprecated, so we can assume that it won't be in Perl 6.
Maybe the real problem has gone away? No. RFC17 specifically
mentions $^W, which has exactly the same problem. Some function
eleven calls down in some module that was loaded by some other module
might do
$^W = 1;
(or $PERL::CORE{warnings} = 1 if you prefer) and suddenly change the
warning behavior of *every* part of your *entire* program. If $* were
not a global, it would be at worst an odd wart, and possibly even a
convenience. Because it is a global, it is a dangerous hazard. $^W
is similar.
$/ is a necessary evil that must be carefully used because it is a
global. If you set $/ and forget to localize the change, the rest of
the program blows up in a bizarre way because *every* filehandle read
operation in (every* part of the program changes behavior. If $/ were
per-filehandle, or if it were lexically scoped, it would be an
unmitigated advantage.
Similarly for each of $\ $, $" $; $# $* $= $^L $^A $@ $^I $^P $^R $^W
and especially the putrid $[.
$| $^ $~ are less problematic because they are per-filehandle.
$. $% $` $& $' $- $+ @+ @- $? $! $^E $$ $[ $^O $^R $^T $^V are less
problematic because they are read-only. Some, like $., are still
problematic, because, for example:
$line = <FH>;
subr();
print "Line $. is $line";
might work, or it might not.
$0 $< $> $( $) $^C $^D $^F $^H $^M @ARGV are not problems because they
really are global. Each process has one real UID, and only one, so a
global variable for $< is perfectly OK.
$_ is in a class by itself.
Summary of manifesto: Global variables must be expunged.
Replacing the old rotten global variables with new rotten global
variables is not enough of an improvement.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
