Bo Peng wrote:
Right, but as I said in the reply to Andre, my point was supposed to be
just that we should have a simple, consistent interface. I don't myself
care whether it is the current one or a new one, though it's an argument
in favor of the current one that (a) it works just fine and (b)
re-writing it would be a lot of work. What we should not do, it seems to
me, is have inconsistencies in the interface. My point was that Bo's
code gives us precisely that. The interface is so inconsistent that the
example code I gave can lead to crashes.
I do not know which crash you are talking about
This was mentioned in an earlier message. It's not an actual crash but a
potential crash. See below.
but as I have said,
params is not enough to make InsetBibtex run smoothly, reconstructing
EmbeddedFileList each time from param is likely to lead to crashes.
But your original code DID reconstruct EmbeddedFileList:
LFUN_INSET_MODIFY called createBibFiles(), which deleted the old
structure and built a new one from scratch, and this happened every time
the user edited the inset. You and I agreed a while ago that we
shouldn't reconstruct this each time. Apparently, it worked, but it's a
bit of a waste. So I fixed that and renamed createBibFiles to
updateBibFiles, and now it's not reconstructed each time, but we just
update the ones that need updating. The same code appears in my patch.
That's where I got it.
I think the issue here is being misunderstood. We agree that (given the
current implementation of embedding), we need to have both these
structures, and we have to keep them in sync. The issue is just whether,
when we need to access the parameters, we should do so by looking at
InsetCommandParams, which is the way most of the code works, or whether
we should look at the EmbeddedFileList. Now, if they're in sync, like
they're supposed to be, it doesn't really matter, except that it does: I
want all these insets to use a consistent interface to the parameters,
for maintainability reasons if no other; and I want to separate the guts
of the inset from the embedding stuff, so that, if the embedding stuff
changes, we don't have to re-write the guts of the inset. This seems
like standard encapsulation sort of stuff. And indeed...
Anyway, if we eventually agree on how embedding *should* work, I can
give up on this discussion and leave InsetBibtex to you, as long as
you do not change EmbeddedFile interface that much.
this illustrates the point: We shouldn't have to wait until we decide
how embedding works to figure out how we iterate over the bibfiles. Of
course, embedding will interact in SOME ways with the inset. But it
should be used where it is needed, and not used elsewhere.
Warning you again, that, please produce valid EmbeddedFileList each time you
update your
params.
That I understand now.
rh
