I don't feel comfortable with the statement "these visitors are then free to specialize on matchers or not ...". Let's think how this API will be used .. today, the user has two hooks - the QueryParser and Collector. Collector allows you to plug in your own and by extending QP you can return your own Query for different fragments.

The Query is a full set though - Query + Weight + Scorer. Whether you extend an existing query and just override one of the methods is up to you, but still the Query is self contained.

If we break the Query API down to a Matcher and Scorer, how will you provide your own Scorer? Collector is independent of the Query - it just collects the results. Will the Scorer be independent of Query too (and become an IndexSearcher.search() argument)? I don't think so, 'cause you want to know which Matcher you're up against in order to write a good Scorer. There's no point passing in a PhraseScorer if the query does not include any PhraseMatcher. So will you need to extend Query, to return your own custom Scorer, for certain fragments? Can't you do it today already (given the API is not final, is public/protected etc.)

Earwin - is that what you had in mind? If so, let's think first if the current API is not sufficient, given that we 'open' it for extension ... e.g., can someone achieve that by extending PhraseQuery, override createScorer and return his own? Do we need more than that?

I'm not saying we should refactor the API to Matcher + Scorer, just thinking on what do we really need to do and what's the best way to achieve that.


On Wed, Jun 9, 2010 at 2:24 PM, Earwin Burrfoot <earwin@gmail.com> wrote:
> Can we represent the Query
> state in some general structure, that no matter which Query you get, you'll
> know how to score it?

No. You could go for unified interface that allows you to express
different query states, like a set of untyped key-values, but you'll
end up switching on these keyvalues in the end.

It's better to define a set of matchers, and then produce visitors
that compute scores. These visitors are then free to specialize on
matchers or not, or ignore the whole tree completely.

Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785

To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org