: 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 ... http://www.nabble.com/Filter-t1002705.html#a2605686 :) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]