On Tuesday 23 May 2006 20:05, Chris Hostetter wrote: > > : I'll repeat the DocIterator from that thread: > : > : public interface DocIterator { > : public int doc(); > : public boolean next(); > : public boolean skipTo(int target); > : } > : > : to come to my question: should that interface should also have an > : explain(int docNr) method? > : When so, it does more than iterating, so it might even be called Matcher. > : Or would both DocIterator and Matcher be useful? > > that's a damn fine question, and the most opinionated answer i can give, > is "i don't know". > > Setting aside for the moment discussion about refactoring a common > interface used for both scoring and filtering, Let me raise some seemingly > unrelated questions: > 1) Does it make sense from an API perspective for both Weight and Scorer > to have explain methods (ignore migration issues that might be > involved in making the change naow, imagine if we were starting from > scratch) ? > 2) Should Weight.explain(IndexReader,doc) allways call scorer(reader).explain(doc)? > 3) Should Weight.explain be deprecated in favor of usage in #2 > 4) should Scorer.explain be removed, and Weights that want to delegate > to their Scorer can do so if-and-only-if the Scorer class they use > specificaly declares the method (as oppose to now where many Scorer > implimentations throw UnsupportedOperationException when they expect > their corrisponding Weight to take care of it > > ...in my optinion, the answers to those questions should drive any > question of wether a "Matcher" API which is intended to be > implimented/superclass of Scorer should contain an explain method. And > assuming the idea of being able to "explain" Filter's appeal to people, > then should the Filter API have an explain method ala Weight, or should > the Matcher returned by Filter.getMatcher(IndexReader) have an explain > method. > > > I honestly don't know. > > : I don't know whether interfaces or abstract classes would be better for this. > > At this point ... i think many interface/abstract-class decissiosn in > Lucene have to be based more on the migration path of least change > then by any sense of correct design principles.
As far as I can see the smallest change would be the SkipFilter1.patch here: http://issues.apache.org/jira/browse/LUCENE-328 This makes Filter implement SkipFilter and it lets IndexSearcher use the SkipFilter implementation when it is available. The SkipFilter interface is here: http://issues.apache.org/jira/browse/LUCENE-330 The next step would then be a global replacement of Filter by SkipFilter in all API's, together with the addition of a test for filter instanceof Filter in IndexSearcher for backwards compatibility in case no DocNrSkipper is provided as SkipFilter. To allow adding things in DocNrSkipper (for example a method nextDocNr() without argument), DocNrSkipper could be implemented as an abstract class instead of as an interface. Explaining a filter might be done by FilteredQuery only. Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]