Richard Heck wrote:
> The obvious way to handle this is to have something like this:
> enum Optional { OPT, REQ };
> struct ParamInfo {
> std::string paramName;
> Optional opt;
> docstring value;
> }
> class ParamList {
> setValue(std::string name, docstring value);
> getValue(std::string name);
> isOptional(std::string name);
> addParam(ParamInfo);
> private:
> std::list<ParamInfo> plist;
> }
> And then every InsetCommand would have an associated ParamList in its
> InsetCommandParams.
>
> So the question is: Are the added memory requirements here
> objectionable? If so, is there some natural way to continue with the
> static const treatment, even assuming the acceptable parameters could
> vary, and even be set at runtime? It's because I don't see how to do the
> latter that this plan seems the only workable one.
It looks like a sane plan and doesn't look especially expensive to me. You
might even take this one step further to:
enum Optional { OPT, REQ };
struct PropertyDefinition {
std::string paramName;
Optional opt;
// Some helper functions defining what might be meant
// by "valid" values.
};
struct Property {
PropertyDefinition propDef;
docstring value;
};
Doing that, you would have essentially define a schema that you could go on
to use to validate your input data.
Presumably "well known" insets would have hard-coded ParamLists and custom
Flex insets would define them in the equivalent of a .layout file.
(Whatever this thing is called for these clever beasties.)
--
Angus
