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. > > Damian > 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.
~jerry
