This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons [EMAIL PROTECTED]
Date: 3 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 17
CVSID: $Id: RFC17.pod,v 1.3 2000/08/07 18:32:04 scs Exp $
=head1 ABSTRACT
Perl currently contains a large number of state and status variables
with names that resemble line noise (henceforth called C$[linenoise]
variables).
Some of these are (or should be) deprecated, and the naming methods for
the rest are obscure. Since we are (potentially) adding, removing, and
changing the functionality of these variables with Perl6, we should seize the
opportunity to rationalize the names and organization of these variables
as well. These variables need to be made available with mnemonic names,
categorized by module, be capable of introspective use, and proper
preparation made for deprecation and translation.
=head1 DESCRIPTION
CPerl allows for the runtime examination and setting of a number of
variables. These existing C$[linenoise] variables are horrible names and
need cleanup, re-organization, and syntactic sugar. Different variables
have different problems, usually one or more of the following:
=over
=item *
unused (as far as we know)
=item *
useless, but still appear in older programs
=item *
duplicated by other features
=item *
standing in the way of advance because of backwards compatibility
=back
In the pre-RFC discussion of this issue, it was also pointed out
that these variables are hard to deprecate without nagging the crap
out of users running the programs. The proposed solution was
broadly applicable, and has been spun off into RFC 3.
The use of the CEnglish module is an attempt to solve the anti-mnemonic
features of these variables. A better solution is to do it right in
the first place, with a number of attendant wins:
=over
=item *
no need for Yet Another Module to be loaded
=item *
promotes code readability
=item *
probably promotes core Perl maintainability
=item *
grouping sets of variables together by function gives
the code writer strong hints as to variables that might
affect each other
=item *
should we move formats (or any similar current core functionality)
to a loadable module, this neatly encapsulates all the data with
a single referenced name
=item *
solves problems with C$[linenoise] variable proliferation
=item *
potentially promotes introspection - see below.
=back
In addition, many features which are now (re)set by other calls should
set appropriate state variables as well. Thus a Cperl script which
contains:
use strict foo;
might set a var C$PERL_STRICT{foo}, and so forth (this is probably
a poor example).
Credit where it is due: the idea of putting related values together into
an appropriately tagged hash is shamelessly ripped off from common Ctcl usage.
=head3 Caveat - Global State Variables Are Dangerous
Having the setting of simple variables modify the function of a
broad set of things is an inherently dangerous and inelegant way of
doing things. Mark-Jason Dominus [EMAIL PROTECTED] has proposed that
they simply be removed whenever possible. I tend to agree with his
arguement, and join in urging that the problems he addresses in message
C[EMAIL PROTECTED] be addressed by the core teams
working in the areas that use such variables. The thread started my
Mark-Jason in Cperl6-language has a good discussion of the issues.
Notwithstanding, should the core team continue to allow global
variables for some purposes, the names and categorization should
be improved.
=head2 Advantages and Non-Loses
=head3 Clean Backwards Compatibility
To promote backward compatibility, one could write a Cuse antiEnglish
module which would alias the old names to the new ones. That Would Be
Wrong, but someone will probably do it - so it may as well be us.
Obviously we cannot provide backwards compatibility for a variable
whose meaning has changed or which has vanished, but most of the
rest can be captured cleanly.
=head3 Promoting Removable Core Modules
It has been strongly proposed that `core Cperl' be broken down internally
into a number of modules such that one could build smaller or larger
custom perls. This feature would ease that work, and possibly set a
standard for how well-behaved non-core modules should implement such
things.
=head3 Provide Possible Guidelines To Core-able Modules
The discussion of removable core modules has strongly implied (sometimes
explicitly stated) that sites could take modules which are not currently
in the core and move them there. Having a standard which those modules
could follow for variable setting and exposure would be a major win.
=head2 Disadvantages
=head3 Backwards Compatibility
Existing Cperl code which makes use of C$[linenoise] variables
which had not changed meaning in Cperl6 will fail if (as proposed)
the
