I'll top-post this only because my remarks don't interweave cleanly with
these comments, for which, thanks.
Here's why I don't want to assume that insets have fixed parameter
lists. Two use cases:
(i) Bibliography support. We need to move away from hard-coding
CiteEngines toward a more flexible sort of system. That's the next
project, and the one that matters on the user's end, and all of this is
cleanup to get ready for that. The point is that there's no telling in
advance what parameters a CiteEngine might want insets to take. Compare
jurabib and natbib, for example---let alone biblatex---and there's no
reason they all have to agree.
(ii) Inset customization. We now allow for user-defined text insets,
thanks to Martin. I can see several cases where it would be nice to be
able to define my own InsetCommand, taking parameters I specify. These
would be read from layout files or, better, modules.
So if you assume we're going that way, then the problem I mentioned
arises. True, we'll need to make sure that we don't get bad mixtures of
InsetCommand's and InsetCommandParam's. I'm hopeful that elements of
what I'm doing will help prevent that. In fact, I basically got started
on this because of a similar problem: that you could alter Param's an
inset expects from the minibuffer---not even from inside the code---and
thereby cause a crash. The solution towards which I'm working is to get
each inset to tell us what parameters it wants for each command with
which it might be associated. That is:
virtual ParamList InsetCommand::getParamList(std::string cmd);
replacing InsetCommandParams::findInfo(). Actually, findInfo will still
be needed, but it will just call InsetFoo::getParamList(), after
switch'ing on the InsetCode. And since each InsetCommandParam's now
stores the type of inset with which it's associated, as an InsetCode,
there's no possibility of mixing up which inset it goes with.
Anyway, that's the plan.
Richard
Georg Baum wrote:
Richard Heck wrote:
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
