: 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]

Reply via email to