Richard Heck wrote: > I take it that the idea is that we don't have to store the list of > parameters, whether they're optional, etc, in each and every inset, but > rather use a reference to the static const construct to save memory.
Saving memory was not the main reason for this implementation, it was rather a nice side effect. > But the problem, from my point of view, is that, in trying to make this > more flexible, we don't want to assume that each inset has a fixed list > of parameters that it will accept. I think that this is a very useful assumption, because it enables you to guarantee by design that an inset has only valid parameters. This was the main reason for this implementation. > And then every InsetCommand would have an associated ParamList in its > InsetCommandParams. And you can easily construct invalid insets and need to implement additional checks to prevent that. > 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? IMHO it is not desirable to set the acceptable parameters at runtime. They should be read from a file on startup and afterwards be treated as const. > It's because I don't see how to do the > latter that this plan seems the only workable one. It could be done in analogy to the text class stuff: On startup, read the inset parameter definitions from a file and store them in a global table. This table would look very similar to your ParamList, but without public setValue(). Each inset would then store a pointer/reference/index/whatever into this list instead of a full ParamList copy. Georg
