> > int widest_bib_item(Inset const * inset, int widest_so_far) {
> > if (inset->name == "Bib" && inset->width > widest_so_far)
> > return inset->width;
> > return widest_so_far;
> > }
> > and then do something like this on the document inset:
> >
> > int widest_bib_item = document->apply(widest_bib_item, 0);
>
> There's a bug unless I've totally misunderstood.
No, I think this would do fine.
Suppose we have three insets:
Inset1: Bib inset. Width 5.
Inset2: Foo inset. Width 20.
Inset3: Bib inset. Width 10.
The order of evaluation would be this (pseudo-code):
int apply(widest_bib_item, int value) {
int temp = value; // temp is 0 from the value in the apply() call.
temp = widest_bib_item(Inset1, temp); // temp is now 5.
temp = widest_bib_item(Inset2, temp); // temp is still 5.
temp = widest_bib_item(Inset3, temp); // temp is 10.
return temp;
}
There is no bug, as far as I can see...
Of course, we need to abstract the apply-interface some more, so that we can
apply things that work on different things than ints. (That was the stuff I
listed a few mails back.)
[Reflection of insets.]
> Hmmm... yes and no.
> So long as we don't fall into the trap of hardcoding inset types into the
> kernel. These manipulators (that are applied) are okay by me though since
> they are not in the kernel but form a library of useful functions.
Yes, that makes sense.
We thus declare a policy that the kernel will not use the inset type
information.
Greets,
Asger
