Hello all, Why is MatchDecider::operator() a const in the C++ API? An implementation of MatchDecider might want to store stuff in member variables so the decision on one document can depend on other decisions already made on previous documents. There must be a valid reason why it's const but I can't see. Thanks, Eric.
On Wed, Oct 01, 2008 at 03:28:08PM +0100, Eric Sellin wrote:> Why is MatchDecider::operator() a const in the C++ API? > > An implementation of MatchDecider might want to store stuff in member > variables so the decision on one document can depend on other decisions > already made on previous documents.Wouldn't you need to guarantee the order in which documents are processed for this to work? J -- /--------------------------------------------------------------------------\ James Aylett xapian.org james at tartarus.org uncertaintydivision.org
Richard Boulton
2008-Oct-01 16:54 UTC
[Xapian-devel] C++ MatchDecider::operator() is const
Eric Sellin wrote:> Hello all, > > Why is MatchDecider::operator() a const in the C++ API? > > An implementation of MatchDecider might want to store stuff in member > variables so the decision on one document can depend on other decisions > already made on previous documents. > > There must be a valid reason why it's const but I can't see.That's a good question. I'm actually not certain it should be const, and perhaps it's something which should be fixed in future. However, fixing it would be a fairly intrusive API change, and would require any user subclasses to be updated, so I wouldn't be happy doing this until the 2.0 release (and I'm not convinced it's worth the effort, overall). It's easy enough to mark members as mutable in the meantime, if you really want to. Note, however, that Xapian does not give you any guarantees about the order in which the match decider is applied to documents, and doesn't guarantee that it will be called with all the potential matching documents. (At least, I don't think there's any guarantees about the order in which it will be presented with documents in the documentation anywhere - I'm willing to be disproved! It certainly often doesn't see all the potential matches.) Therefore, it's not safe to base the decision on previously seen documents. This is why the const was originally introduced, as far as I can recall - to try and make this clear to users. Since matchdeciders were introduced, the "matchspy" parameter has been added to get_mset(). This takes a match decider, and can be used to select a subset of the potential matches, but is called a bit earlier in the match process, and it is guaranteed to be called on at least "checkatleast" documents. The intention is that this allows the "matchspy" MatchDecider subclass to be used to count features of the supplied documents (for example, the matchspy branch contains some matchspies which count the occurrences of values in value slots, which can be used to present relevant facets or tags for refining the search results). Of course, a matchspy can only really be useful if it has mutable members, which is why I feel it might be reasonable to remove the const. -- Richard