jerry gay wrote:
On Wed, Aug 4, 2010 at 15:56, Damian Conway <dam...@conway.org> wrote:
Specifically, I think it would be easiest to be consistent and say
that all purely lowercase and all purely uppercase config option names
are reserved, and that unrecognized reserved config options generate
at least a warning when they are parsed. Mixed-case config options
should be freely available to users and the parser should simply
accept them without complaint and include them in the internal data
structure it builds, whereupon they will be available to user-defined
Pod extensions.
are there codepoints in unicode that may be either upper-case or
lower-case, depending on the charset? if so, then there's ambiguity
here, depending on the user's locale. i suspect not, but languages
are strange beasts, and i don't know the answer.
There's a simple solution to that.
Just say that names consisting entirely of either ASCII-range uppercase letters
or ASCII-range lowercase letters are reserved, and that names having either both
of those or any of those plus non-ASCII letters are not reserved.
The only way I see this being a problem is if we forsee that we might want to
have official names going out of the ASCII repertoire, which I would recommend
we don't.
-- Darren Duncan
