RE: [reSIProcate] Username as a quoted field => Parameter implementation question
> Question for david: why is there a defineParam in Auth.hxx,
> ParameterTypeEnums.hxx, ParameterTypes.hxx/cxx, ParserCategory.hxx/cxx and
> what happens if they are inconsistent?
ParameterTypeEnums.hxx (not a great name) defines the enums that underlie
the parameters. In theory, this is where you turn off a parameter as built
in for a compilation.
ParameterTypes.hxx/cxx declare and define the parameter token types, not to
be confused with the actual parameter types (which in turn are, of course,
not to be confused with the types that implement each the parameters -- a
much smaller set. All clear now?)
ParserCategory.hxx/cxx declare and defines the accessors for the parameters
in terms of their token types.
Auth.hxx is a pain because it has its own syntax and parameter set. Here
again we are declaring and defining accessors.
Inconsistencies often lead to compile errors. But I agree completely with
the implication that this is an unfriendly way to maintain code.
As some of you know, macros were not my first choice for implementing all of
this. However, cooler heads prevailed and crazy-Russian style templates were
ruled out. My preference is to have a configuration file each for headers,
methods, and parameters that drives what code gets generated and also drives
the hashing functions (and output arrays, as pointed out by Alan).
Alan's suggestion of having the configuration file be included after the
requisite macro definition is clever, and may be a worthwhile incremental
improvement, but I would prefer to solve the entire problem.
I would be delighted to get rid of the (expletive deleted) macros.
david