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
> Wouldn't you need to guarantee the order in which documents are > processed for this to work? Yes, quite. So that's why it's const. Because documents are processed in a random order, each document must be considered for inclusion on a purely individual basis, otherwise we get random results. Many thanks, Eric.
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.(Continue reading)
On Wed, Oct 01, 2008 at 05:54:20PM +0100, Richard Boulton wrote: > Eric Sellin wrote: > > Why is MatchDecider::operator() a const in the C++ API? > > [...] > > 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). I'm pretty much convinced it isn't. The issue of whether this should be const or not is arguable, but while "x.0" is a chance for making incompatible changes when there's a good reason, it shouldn't be taken as an excuse to change things just because we can. It requires users to update their code, and complicates code which wants to support the old and new APIs for a transitional period. > 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.) The intention is certainly that a MatchDecider should make an independent decision about each document. Currently the order is actually ascending docid order, but we certainly(Continue reading)
On Thu, Oct 02, 2008 at 11:41:10AM +0100, Olly Betts wrote: > The intention is certainly that a MatchDecider should make an > independent decision about each document. Can you cast away the constness of ``this''? I believe this is how you'd implement caching, so there is a route for people who really know what they're doing. Or I might be wrong. It's been a while since I got enough sleep to think in C++ :-/ J -- -- /--------------------------------------------------------------------------\ James Aylett xapian.org james <at> tartarus.org uncertaintydivision.org
On Thu, Oct 02, 2008 at 12:31:35PM +0100, James Aylett wrote:
> On Thu, Oct 02, 2008 at 11:41:10AM +0100, Olly Betts wrote:
>
> > The intention is certainly that a MatchDecider should make an
> > independent decision about each document.
>
> Can you cast away the constness of ``this''? I believe this is how you'd
> implement caching, so there is a route for people who really know what
> they're doing.
For caching, the usual approach is to declare the members variable(s)
concerned as "mutable".
Cheers,
Olly
On Thu, Oct 02, 2008 at 12:34:31PM +0100, Olly Betts wrote: > > > The intention is certainly that a MatchDecider should make an > > > independent decision about each document. > > > > Can you cast away the constness of ``this''? I believe this is how you'd > > implement caching, so there is a route for people who really know what > > they're doing. > > For caching, the usual approach is to declare the members variable(s) > concerned as "mutable". Ah, yes. Tricksy stuff, C++. J -- -- /--------------------------------------------------------------------------\ James Aylett xapian.org james <at> tartarus.org uncertaintydivision.org
_______________________________________________ Xapian-devel mailing list Xapian-devel <at> lists.xapian.org http://lists.xapian.org/mailman/listinfo/xapian-devel
On Tue, 7 Oct 2008 14:02:14 +0800, Allen wrote: > How can i get the source of xapian If you go to the Xapian website on http://xapian.org/ and click on "download" you will find instructions on how to get the latest release on many, many systems. If you want the latest developement code, you can click on "bleeding edge" instead. Best regards, -- -- "I wanted a computer, not a glorified fruit machine." Adam Sjøgren asjo <at> koldfront.dk
RSS Feed2 | |
|---|---|
19 | |
4 | |
11 | |
14 | |
15 | |
37 | |
57 | |
93 | |
11 | |
9 | |
6 | |
2 | |
9 | |
5 | |
7 | |
4 | |
9 | |
5 | |
3 | |
3 | |
11 | |
6 | |
20 | |
4 | |
14 | |
22 | |
24 | |
4 | |
6 | |
16 | |
4 | |
8 | |
11 | |
8 | |
1 | |
21 | |
5 | |
9 | |
3 | |
11 | |
6 | |
19 | |
24 | |
2 | |
5 | |
30 | |
26 | |
146 | |
57 | |
44 | |
12 | |
32 | |
44 | |
23 | |
6 | |
20 | |
11 | |
34 | |
22 | |
70 | |
13 | |
4 | |
8 | |
17 | |
11 | |
2 | |
4 | |
22 | |
19 | |
19 | |
24 | |
9 | |
8 | |
11 | |
1 | |
41 | |
4 | |
17 | |
16 | |
17 | |
41 | |
4 | |
3 | |
16 | |
2 | |
27 | |
1 | |
15 | |
65 | |
29 | |
32 | |
25 | |
29 | |
37 | |
20 | |
25 |
