Before jumping in on this, keep in mind that Larry Wall has already
stated his intent to just plain _eliminate_ many of these special
variables. Most of them suffer from the "action-at-a-distance"
problem, meaning you change something somewhere and unexpected changes
occur elsewhere.
For example, for years old perl4 libraries that accessed arrays had
to do unwieldy arithmetic with $], which was used to control the
number at which array subscripts started. This was, in some sense, a
great feature since you could select array behavior closest to the
language you came from (0-based for C folks; 1-based for BASIC folks;
or whatever), but once people tried to create libraries it became
apparent that this variable caused code authors to stomp all over each
other, and so it is deprecated.
As another example, at work we are in love with the $/ variable,
since we often deal in multi-line records delimited with control-Y's.
However, changing this variable affects _everything_, meaning modules
you want to use might not work unless you only modify $/ with local()
within a subroutine. The solution is for the concept of $/ to become
a per-filehandle value, as in, encapsulation and object-orientation.
Larry implied that there might not be much left when all these
variables are cleaned up, but if there are, the approach suggested
earlier of putting them in a more descriptively-named hash might be
all right.
I suggest that the most productive thing to do right now is go
through the special variables manpage and make a list of how the
*feature* provided by each variable should be re-implemented to avoid
action-at-a-distance problems. Any volunteers?
J. David
