> > There are then some minor problems left, such as 1. In functions such > > as addDatabase, should we update params first and update > > EmbeddedFileList/Map; or another way around? > > > or encapsulate it in overridden setParam methods, so you can't forget to > do it.
I disliked your implementation of setParam because if you set params first, and then update EmbeddedFileList, you may be bounced back to set params again (to disable embedding). On the other hand, if you update EmbeddedFile first, you do not have to do this. Anyway, all these can happen in setParam and the differences are trivial. > > 2. When we are in need > > some information, from whom should we ask for it? I say they are minor > > problems because if params and EmbeddedFiles are in sync, it does not > > really matter, so let use just use the easier method. > > > > > Iterating over params is more sensible, I think, if only because, if > embedding is not enabled, you needn't consult anything else. Exactly > what the code will look like, I don't yet know, but we'll have things like: > string const database = > buffer().enabled() ? consult(paramIterator->first) : > paramIterator->first; > We'd anyway have (more or less) > string const database = > buffer().enabled() ? bibfilesIterator->availableFilename() : > bibfilesIterator->metaInfo(); > So it doesn't end up mattering that much, and the former makes it > clearer exactly where the information from EmbeddedFiles is used and > where it is not. I will have to see your patch (or commits) to determine if I like it, but you know I dislike parsing params again and again. :-) Bo
