On Wed, Aug 4, 2010 at 15:56, Damian Conway <dam...@conway.org> wrote:
> Carl proposed:
>> The other path that seems reasonable to me would be to use the same
>> naming scheme as for the block types, i.e. reserve all-upper and
>> all-lower forms (and die if an unrecognized one of this form is
>> encountered), and let the custom ones live in the namespace of
>> mixed-case identifiers. That sounds sane to me as well; the only
>> question is whether that much structure is needed for config options.
> I did not consider this issue when designing S26, but in considering
> it now, I think Carl's suggestion is entirely sensible and in line with
> what I intended.
> 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.