Sorry for the top-post, but, after lots of thought about this, I've come
to the conclusion that Georg is right, and we shouldn't go the way I was
suggesting. There's then a different design problem that arises, but
I'll post a note about that later. That said:
IMHO the text classes are pretty
Richard Heck wrote:
> Here's why I don't want to assume that insets have fixed parameter
> lists. Two use cases:
I believe there is a misunderstanding here. With "fixed parameter list" I do
not mean a hardcoded list in the source. I do mean a list that gets read
from some configuration file and i
Andre Poenitz wrote:
On Fri, Oct 19, 2007 at 12:24:50AM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
So the question is: Are the added memory requirements here
objectionable?
How much would that be?
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 flexi
On Fri, Oct 19, 2007 at 12:24:50AM -0400, Richard Heck wrote:
> Andre Poenitz wrote:
> >On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
> >
> >>So the question is: Are the added memory requirements here
> >>objectionable?
> >>
> >How much would that be?
> >
> I don't know C++
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,
Andre Poenitz wrote:
On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
So the question is: Are the added memory requirements here
objectionable?
How much would that be?
I don't know C++ internals enough to be sure how much we're talking per
inset. We're looking at, on av
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, docstr
On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
> So the question is: Are the added memory requirements here
> objectionable?
How much would that be?
Andre'
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 do
10 matches
Mail list logo
