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]

Reply via email to