=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 17
=head1 ABSTRACT
Perl currently contains a large number of state and status 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 vars 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. A partial backwards compatibility
mechanism is suggested.
=head1 DESCRIPTION
Perl allows for the runtime examination and setting of a number of
variables. These existing C<$<linenoise>> vars are horrible names and
really need some cleanup and syntactic sugar. Different variables
have different problems, with some having one or more of the
following problems:
=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 C<English> 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 perl 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 C<tcl> usage.
=head2 Advantages and Non-Loses
=head2 Clean Backwards Compatibility
To promote backward compatibility, one could write a C<use 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.
=head2 Promoting Removable Core Modules
It has been strongly proposed that `core perl' 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.
=head2 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
Literally none have been broached on the various C<perl6> mailing lists.
=head2 Other Possible Features
It has been suggested by Alan Burlison <[EMAIL PROTECTED]>
that this allow for localizable settings. Thus module A might
turns warnings off when its features are in use, while module
B is unaffected by the setting done by module A. This is a change
in the functionality of such settings, and has the potential for
broadly changing what happens in perl. I suggest that this
issue is actually independent of how the variables are named,
and should be taken to another RFC if anyone is interested.
=head1 IMPLEMENTATION
=head2 Internal Implementation
The internal representation of these is largely irrelevant(!).
This RFC prescribes what the I<external> interface looks like;
the implementation team should select whatever mechanism they
prefer for internal use. It's probably a maintenance win if
the same is used, but the proposers don't intend to dictate
to the developers.
=head2 External Implementation
Variables should be sorted into functional areas which may or
may not have a one-to-one correspondence with internal (core)
There have been four suggestions for how the variables should
be named.
In the examples below, I have capitalized the higher-level
portions of the names. This capitalization is not a requirement
of the RFC, and is done purely to make the new names stand out
in this document.
=head3 Well-Named Global Hashes And Keys
For each collection of variables, a well-named pseudohash with
well-named keys:
$PERL_CORE{warnings} vs $^W
$PERL_CORE{version} vs $^V
$PERL_FORMATS{name} vs $^
$PERL_FORMATS{lines_left} vs $-
$PSEUDO_HASHES{strict} vs (none)
An additional variable should be provided,
$PERL_CORE{variables}
which contains a list of all the settable hash names (eg,
$PERL_CORE{variables} = qw(PERL_CORE PERL_FORMATS PSEUDO_HASHES ...)
Advantages: Only a single point in the namespace is used for each
variable. The hashes can be handed around en masse efficiently
via references. Pseudo-hash member access is efficient.
Names are free from module dependency. Introspection with hashes
is more powerful (see below).
Disadvantages: Pseudo-hashes are new to most programmers.
=head3 Well-Named Module Variable Sets
This has an almost one-to-one naming match to the first suggestion,
but used module naming:
$PERL::CORE::Warnings vs $^W
$PERL::CORE::Version vs $^V
$PERL::FORMATS::Name vs $^
$PERL::FORMATS::LinesLeft vs $-
$PSEUDOHASH::CONTROL::Strict vs (none)
Advantages: Looks like individual variables again. Modules could
be moved (compiled) in and out of the perl core and, so long as
a script did the appropriate C<use/require> statement, the script
would require no other changes.
Disadvantages: Locks variables into given modules. The second-level
names may become difficult to do sensibly.
=head3 Well-Named Per-Module Hashes And Keys
This is a hybrid of the first two:
$PERL::CORE{warnings} vs $^W
$PERL::CORE{version} vs $^V
$PERL::FORMATS{name} vs $^
$PERL::FORMATS{lines_left} vs $-
$PSEUDOHASH::CONTROL{Strict} (none)
Advantages: Looks like individual variables again. Modules could
be moved (compiled) in and out of the perl core and, so long as
a script did the appropriate C<use/require> statement, the script
would require no other changes. Introspection and variable
discovery via C<keys %PERL::CORE> is still a win.
Disadvantages: Locks variables into given modules. The second-level
names may become difficult to do sensibly. Introspection becomes
more difficult because one must find the second-level name(s) for
each class of item (eg, PERL::CORE and PERL::FORMATS).
=head3 Introspection With Hashes
The use of hashes and pseudo-hashes leads to a straightforward and
`natural' mechanism by which programmers can discover all the
relevant variables for a given item:
foreach my $key ( %PERL_CORE ) {
print "\%PERL_CORE{$key} is $PERL_CORE{$key}\n";
}
=head3 Summary
The RFC author thinks the first suggestion, I<Well-named Global Hashes
and Keys>, is the best choice. While it has potential problems
for module removal should a hash be shared between several modules,
these are (IMHO) worth the flexibility of I<not> locking a given
hash to a given module and providing a single, consistent mechanism
programmers would use to obtain value settings.
=head2 Value Protection
A value can be set and reset, but it's existence should be protected.
Thus one could set the variables, but not undefine or delete them.
If hashes are chosen, the user should not be allowed to add or
remove key/value pairs from the hash.
Further, values such as $C<PERL_CORE{version}> should be read-only.
=head2 Deprecation Warnings
At a minimum, C<use strict> and C<perl -w> should warn of the
use of deprecated variable names. That deprecation warning should
be I<specific>, not simply <var $foo is deprecated>. Messages
should identify the old var, new var, and at least imply an action:
changing var $foo no longer has any effect
the value of var $bar no longer has any meaning
var $baz has been replaced by $FOO_BAR{baz}
and so forth.
In addition, it should be possible to have the programmer detect and
control these messages on a case by case basis. RFC 3
proposes a mechanism by which programmers could take more direct
control of this; should that RFC be accepted then that mechanism
should be used.
Should it fail, we will make a more specific recommendation here.
=head1 CONTRIBUTIONS
Contributions ranging from voluminous commentary to pretty
decent wisecracks have been received from:
Corwin Brust <[EMAIL PROTECTED]>,
Alan Burlison <[EMAIL PROTECTED]>,
Piers Cawley <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]>,
Nathan Wiger <[EMAIL PROTECTED]>
and others who I probably missed. In addition, it's been pointed
out that this suggestion was raised in the past; unfortunately the
fingerprints have long since worn away.
=head1 REFERENCES
RFC 3 on Run-Time Error Message Control
