On 24 Oct 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | XTL via lyxfunc works (or worked) very nicely. Then the external scripts
> | can call lyxfunc with data directly.
>
> In essence this is passing a complex structure to the lyxfunc, and I
> am not sure if I agree with that.
While it is very reasonable to have reservations against such a scheme,
I just want to point out one way of using XTL to ensure backwards and
forward-compatibility in the format.
Suppose we have a class with the members variable1 and variable2.
This is great, and we live with this class for a year, and use the
layout of it indirectly through XTL.
Now, it turns out we need a variable3, so what are we to do? We would
like to support the old layout, but at the same time use the new layout
in the future.
You can easily do this with XTL like this:
template<T>
void simple(T & s) {
int version = 1;
s.simple(version);
switch(version) {
case 0:
s.simple(variable1);
s.simple(variable2);
variable3 = 0;
break;
case 1:
s.simple(variable1);
s.simple(variable2);
s.simple(variable3);
break;
default:
throw "Unsupported version";
break;
}
}
This code will read old format structure without problems.
Also, it will save in the new format.
If you are willing to spare the space at run-time, you can easily
make the code support saving in the same format as it was read.
Conclusion: It's fairly easy to gracefully support different versions
of a physical layout with XTL. That at least lifts one concern about using
an XTL format for internal purposes.
But I agree that there are other issues involved with using an XTL
format for the internal dispatcher as the only available mechanism.
For one thing, it still is too inflexible if it is to gracefully handle
arbitrary input from users via the minibuffer.
Greets,
Asger
