lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Explaining a filter; Scorer extending Matcher; (was: BooleanWeight.normalize(float) doesn't normalize prohibited clauses?)
Date Mon, 22 May 2006 21:43:00 GMT

: In case Explanation is also to explain what a Filter does, it would need to
: have both a match flag and a score value.

that's a good point, i hadn't considered hte possibility of "explaining"
filters much ... but there's no reason why the "valueO 'f an explanation
couldn't be an optional part of the explanation as well (ie: migrate from
float to Float when adding the "Boolean match" so that future Explanation
instances (of Filters) can say they match without claiming a particular
score (or "faking it" with some magic float value)

: At the moment I'm trying to implement filters by refactoring Scorer to have an
: abstract superclass Matcher that could also become a superclass for filter
: implementations (instead of DocNrSkipper).
: This Matcher class has all methods of Scorer that are not using score
: values: doc(), next(), skipTo(docNr).

: Any thoughts on whether such a Matcher would be preferable to
: a DocNrSkipper that only has this method:
:   int nextDocNr(int docNr)

(I'm very ammused by this question, you'll see why in a second)

I am 100% on board with the "Matcher" API you are describing ... but i
think it might make more sense as an interface, perhaps called
"DocIterator", that way even TermDocs could impliment it ...



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message