On Saturday 08 July 2006 05:44, robert engels wrote: > Agreed. The interface I proposed supports both sequential and random > access to the filter - hiding the implementation.
For query searching, random access to a Filter is only needed in the forward direction, e.g. by nextInclude(docNr) or skipTo(docNr). As for why it's so involved: Making a "rewritten" Filter work more like a Scorer has the advantage that combinations of filters can (also) be evaluated using the same mechanisms as currently existing for Scorers. For this, some additions to the existing code will be needed, like adding an add(Filter, BooleanClause.Occur) to BooleanQuery, and a similar addition of a Matcher (proposed superclass of Scorer to "rewrite" a Filter to) to some of the underlying scorers. Such occurrences of filters are only "must" and "must not", "should" doesn't make sense because there is no score value. Also, it makes sense to have an explain() method for a "rewritten" Filter, because it can be for searching a query. Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
