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]
