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.


Reply via email to