So, the work on making this system more flexible proceeds, with
interruptions for actual philosophy from time to time. At this point, I
have a question before I embark on the next step. The question concerns
how the list of parameters is represented in InsetCommandParams.
At present, it's done like this. This struct:
struct CommandInfo {
/// Number of parameters
size_t n;
/// Parameter names. paramnames[n] must be "".
char const * const * paramnames;
/// Tells whether a parameter is optional
bool const * optional;
};
describes the parameters to be used, and it's defined here:
switch (code) {
case BIBITEM_CODE: {
static const char * const paramnames[] = {"label", "key", ""};
static const bool isoptional[] = {true, false};
static const CommandInfo info = {2, paramnames, isoptional};
return &info;
}
etc. The parameters themselves are stored in a separate data structure:
typedef std::vector<docstring> ParamVector;
/// The parameters (both optional and required ones). The order is
/// the same that is required for LaTeX output. The size of params_
/// is always info_->n.
ParamVector params_;
and written in the following sort of way:
int const i = findToken(info_->paramnames, token);
if (i >= 0) {
lex.next(true);
params_[i] = lex.getDocString();
}
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.
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. What parameters it accepts may depend
upon what command it represents: Compare jurabib and natbib and
biblatex, in particular, let alone a to-be-written "custom command
inset" similar to custom Flex insets. 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.
Richard
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
