Lightning flashed, thunder crashed and Perl6 RFC Librarian <[EMAIL PROTECTED]>
whispered:
| =head3 Well-Named Global Hashes And Keys
|
| For each collection of variables, a well-named pseudo-hash 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)
If this were to be used, I'd prefer to see one hash (%PERL or somesuch) and
the keys for these specific examples be qw/warnings version format_name
format_lines strict_pseudo_hashes etc/;
| 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 ...)
A single hash removes the need for this, and allows for keys(%PERL) to give
you a list of all things you can change.
| =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)
|
| Disadvantages: Locks variables into given modules. The second-level
| names may become difficult to do sensibly.
Not really. It only locks them into a given package or class, which is not
a problem. WE can easily move things from the core to a module or to any
number of modules. If we keep most everything within the PERL:: class, the
second level gets a lot easier.
| =head3 Well-Named Per-Module Hashes And Keys
|
| This is a hybrid of the first two:
Probably the best idea of the three to my mind. Same answer as above goes
to the disadvantages.
-spp
